COMPLAINT MANAGEMENT SYSTEM FOR DEBRE BERHAN

UNIVERSITY

Senior Project Documentation Submitted to Debre Berhan University

In partial Fulfillment of the Requirement for the Degree of Bachelor of Science in Information
Technology

Student Name…………………………………………………… ID NO:

1) Tenaw Tagele ……………………………………………………………..145/06

2) Miftah Mohammed …………………………………………...…………..135/06

3) Solomon Mihretie …………………………………………………….…140/06

4) Ashenafi Fikru …………………………………………………...............114/06

5) Mihret Kefyalew…………………………………………………………..136/05

Supervised by: Tesfaye Fufa

Department of Information Technology

College of Computing Department of Information Technology

Debre Berhan University Debre Berhan, Ethiopia

JUNE 2017
APPROVAL

The Project is our own and has not been presented for a degree in any other university with this
functionality and all the sources of material used for the project/thesis have been duly
acknowledged. (Name and Signature of the project group members)

Name signature

1) Tenaw Tagele ……………………………………………………………..

2) Mihret Kefyalew…………………………………………………………..

3) Solomon Mihret …………………………………………………….…

4) Ashenafi Fikru …………………………………………………...............

5) Miftah Mohammed …………………………………………...…………..

This is to certify that I have read this project and that in our opinion it is fully adequate, in scope
and quality, as a project for the degree of Bachelor of Science.

……………………………………………. ……………………………

Name of Advisor Signature

Examiner Name Signature

1. Examiner 1 …………………………………. ………………………

2. Examiner 2 …………………………………… ……………………….

3. Examiner 3 …………………………………… ……………………….

4. Examiner 4 …………………………………… ……………………….

I
 Abstract
The objective of the project, automated compliant management System in case of Debreberhan
University which enables the grievance handling office to record complains in organization,
viewing compliant records, customers register complain easily.. Automated Complain
management System project mainly consists of different types of actors. Those are grievance
handling of organization, employees and customer In general term the function of this project to
manage the information of complain in terms of fast ,managing input/output and advertising.

II
 Acknowledgment
First of all we would like to give thanks for God because helps us every success of our proposal
and analysis phase. Next to this we give thanks for our advisor instructor Tesfaye Fufa for his
excellent advice and guidance to do the project from starting to this phase.

In addition to this we would like to give thanks for all the IT instructors, because they are the
framework to do this project and also thanks for all our friends who provide advice and some
corrections from our error.

III
IV
Contents
Abstract ........................................................................................................................................... II
Acknowledgment ........................................................................................................................... III
1.1 INTRODUCTION............................................................................................................ 1
1.2 Background of Debre Berhan University......................................................................... 2
1.2.1 Vision ........................................................................................................................ 2
1.2.2 Mission...................................................................................................................... 2
1.3 Background of the project ................................................................................................ 2
1.4 Problem description ......................................................................................................... 3
1.4.1 Statement of the problem .......................................................................................... 3
1.5 Team composition ............................................................................................................ 4
1.6 Objective of the project .................................................................................................... 4
1.6.1 General Objective ..................................................................................................... 4
1.6.2 Specific Objective ..................................................................................................... 4
1.7 Scope and limitation of the project .................................................................................. 5
1.7.1 Scope of the project .................................................................................................. 5
1.7.2 Limitation of the project ........................................................................................... 5
1.8 Significance of the project ............................................................................................... 5
1.9 Target beneficiaries of the system.................................................................................... 6
1.10 Methodology .................................................................................................................... 6
1.10.1 Data collection methodology .................................................................................... 6
1.10.2 Interview technique ................................................................................................... 7
1.10.3 Document analysis .................................................................................................... 7
1.10.4 Observation ............................................................................................................... 7
1.11 System analysis and design methodology ........................................................................ 7
1.11.1 Hardware and software Requirements ...................................................................... 7
1.12 CASE (Computer-Aided Software Engineering) tools .................................................... 8
1.13 Requirement structuring and data modeling tools ........................................................... 9
1.14 Feasibility study ............................................................................................................... 9

v
 1.14.1 Operational Feasibility .............................................................................................. 9
1.14.2 Technical feasibility .................................................................................................. 9
1.14.3 Economic Feasibility ................................................................................................ 9
1.14.4 Legal feasibility ...................................................................................................... 10
1.15 Project schedule work break down structure ................................................................. 10
1.16 Cost Breakdown structure of the project ........................................................................ 12
CHAPTER TWO .......................................................................................................................... 13
DESCRIPTION OF THE EXISTING SYSTEM ......................................................................... 13
2 Introduction of existing system ............................................................................................. 13
2.1 Player in the existing system .......................................................................................... 14
2.2 Major Functions in the Existing System ........................................................................ 14
2.3 Business rules ................................................................................................................. 15
2.4 Report generation for the existing system ...................................................................... 18
2.5 Forms and other documents of existing system ............................................................. 18
2.6 Bottlenecks of the existing system ................................................................................. 20
2.7 Practice to be presented .................................................................................................. 20
2.8 Proposed solution for the new system ............................................................................ 21
2.9 System Requirement Specifications ............................................................................... 21
2.9.1 Functional requirement ........................................................................................... 22
2.9.2 Non-functional requirements .................................................................................. 22
CHAPTER THREE ...................................................................................................................... 25
3 SYSTEM ANALYSIS ........................................................................................................... 25
3.1 System models ............................................................................................................... 25
 Actor and use case identification ................................................................................... 25
3.1.1 Scenarios ................................................................................................................. 25
3.1.2 Use case description ................................................................................................ 28
3.1.3 Object model ........................................................................................................... 38
Class diagram is a graph of classifier elements connected by their various static
relationships. .......................................................................................................................... 39
3.2 Dynamic model .............................................................................................................. 40

vi
 3.2.1 Sequence diagram ................................................................................................... 40
3.2.2 Activity diagram ..................................................................................................... 45
3.2.3 State diagram .......................................................................................................... 49
3.2.4 User Interface prototype (Navigational paths and screen mock-ups) ..................... 52
3.2.5 Supplementary Specifications ................................................................................. 53
4 SYSTEM DESIGN ................................................................................................................ 54
4.1 Introduction .................................................................................................................... 54
4.1.1 Purpose of the system ............................................................................................. 54
4.1.2 Design Goal ............................................................................................................ 54
4.2 Current software architecture ......................................................................................... 56
4.3 Proposed software architecture ...................................................................................... 56
4.3.1 Overview ................................................................................................................. 57
4.3.2 System decomposition ............................................................................................ 58
4.4 Hardware /software mapping ......................................................................................... 58
4.4.1 Persistent data management .................................................................................... 59
4.5 Logical database Design ................................................................................................ 63
4.5.1 Access control and security .................................................................................... 64
4.5.2 Global software control........................................................................................... 65
Flow of message between subsystems: ......................................................................................... 65
Concurrent control: ....................................................................................................................... 66
4.5.3 Boundary conditions ............................................................................................... 66
4.6 Subsystem services......................................................................................................... 67
4.7 Component diagram ....................................................................................................... 68
4.8 Deployment diagram ...................................................................................................... 69
5 CHAPTER FIVE ................................................................................................................... 72
5.1 Introduction .................................................................................................................... 72
5.2 Object design tradeoffs .................................................................................................. 72
5.3 Interface documentation guidelines ............................................................................... 73
5.4 Package .......................................................................................................................... 73
Figure 23 Package ......................................................................................................................... 74

vii
5.5 Class interfaces............................................................................................................... 75
5.6 User interface design ...................................................................................................... 75
6 CHAPTER SIX...................................................................................................................... 83
6.1 Introduction .................................................................................................................... 83
6.2 Final Testing of the System............................................................................................ 83
6.3 Hardware Software Acquisition ................................................................................... 102
6.4 User Manual Preparation.............................................................................................. 102
6.5 Training ........................................................................................................................ 103
6.6 Installation Process....................................................................................................... 103
6.7 Start-up Strategy........................................................................................................... 103
7 Chapter Seven ...................................................................................................................... 104
7.1 Conclusions .................................................................................................................. 104
7.2 Recommendations ........................................................................................................ 105
7.3 APPENDIX .................................................................................................................. 106
7.4 References .................................................................................................................... 107

viii
List of figures
Figure 1 Use case diagram for compliant management system .................................................................. 27
Figure 2 analysis class diagram .................................................................................................................. 40
Figure 3 Sequence diagram for create and update account ......................................................................... 41
Figure 4 Sequence diagram for view complaint ......................................................................................... 42
Figure 5 Sequence diagram for handling grievance office send solution to User....................................... 43
Figure 6 sequence diagram for login........................................................................................................... 44
Figure 7 Activity diagram for login ............................................................................................................ 45
Figure 8 Activity diagram to manage account ............................................................................................ 46
Figure 9 Activity diagram for handling Grievance office, user and organ of the compliant view
notification .................................................................................................................................................. 47
Figure 10 Activity diagram for User compliant registration ....................................................................... 48
Figure 11 Activity diagram for handling grievance office send solution ................................................... 49
Figure 12 State diagram for send complaint ............................................................................................... 50
Figure 13 State diagram for Registration ................................................................................................... 51
Figure 14 state diagram for login ................................................................................................................ 51
Figure 15 user interface prototype .............................................................................................................. 52
Figure 16 State diagram for Registration .................................................................................................... 57
Figure 17 system decomposition................................................................................................................. 58
Figure 18 Hardware/Software Mapping ..................................................................................................... 59
Figure 19 mapping ...................................................................................................................................... 60
Figure 20 Database Design ......................................................................................................................... 64
Figure 21 component Diagram ................................................................................................................... 69
Figure 22 Deployment Diagram for compliant management system ......................................................... 71
Figure 23 Package ....................................................................................................................................... 74
Figure 24 Class interfaces ........................................................................................................................... 75
Figure 25 Home Page.................................................................................................................................. 76
Figure 26 Customer registration page ......................................................................................................... 77
Figure 27 List of complain sent to it department ........................................................................................ 78
Figure 28 Complaint view page .................................................................................................................. 79
Figure 29 Descion paper that wii be sent to the sender............................................................................... 80
Figure 30 Home pages in android to integrate with php ............................................................................. 82

ix
List of tables

Table 1 Team composition.............................................................................................................. 4

Table 2 CASE (Computer-Aided Software Engineering) tools ...................................................... 8
Table 3 Project schedule Work Breakdown structure.................................................................. 11
Table 4 Cost Breakdown structure of the project ......................................................................... 12
Table 5 Business rules ................................................................................................................. 18
Table 6 use case description to Login ........................................................................................... 28
Table 7 use case description to register complaint ....................................................................... 29
Table 8 Use case description for update account ......................................................................... 30
Table 9 Use case description for view notification ...................................................................... 31
Table 10 Use case description for send Decision ........................................................................ 32
Table 11 use case description for send feedback ......................................................................... 32
Table 12 Use case Description for View feedback ...................................................................... 32
Table 13 Use Case Description for Search .................................................................................. 33
Table 14 Use Case Description for Logout................................................................................. 34
Table 15 Use Case Description for Change Password................................................................. 35
Table 16 Description of Add User Use Case ............................................................................... 37
Table 17 Use Case Description for Generate Report ................................................................... 38
Table 18 Data dictionary............................................................................................................... 39
Table 19 register table ................................................................................................................... 62
Table 20 message table ................................................................................................................. 62
Table 21 feedback table ................................................................................................................ 62
Table 22 department table ............................................................................................................. 63
Table 23 Access Control ............................................................................................................... 65

x
Abbreviations

Acronym Description
BR Business Rule

DB Database

HTTP: Hypertext Transfer Protocol

GSM: Global System Mobile Communication
GUI: Graphical User Interface
HRM: Human Resource Management
MYSQL My Structural Query Language
OS: Operating System
SMS Short Message service
SDD Software Design Document

xi
 CHAPTER ONE

1.1 INTRODUCTION
E-government allows citizens to interact with government to achieve objectives without being
restricted to time and location, and eliminates the necessity for physical travel to government
agents. Taking this into consideration, e-government applications are being developed [1]. The
government of Ethiopia has launched an E-service portal by aiming improving public services to
citizens, residents, businesses, and brings its institutes closer to stakeholders by which citizens
and businesses are able to request public services electronically and get response accordingly [2].
The portal allows users to provide their feedbacks for future improvements.

In Skielse [4] stated that emergent area in which citizens can interact with government is M-
government or mobile government. It is a natural extension to e-Government and one promising
area of m-government is complaint and problem management, where mobile applications used to
offer citizens convenient ways of rapidly reporting problems and to express their dissatisfaction
with procedures and services of a government entity. As the complaints hold the voice of the
citizen they provide critical knowledge about the organization and its service which can be
utilized for the improvement of the organization.

As supposed by A. Mulatu [1], due to increasing wider acceptance and usage of smart phones
worldwide, it is expected that the number of smart phone users in the country will increase.
According to [3], the use of mobile for internet growing and the demand for mobile services and
internet access continues to grow exponentially. Hence, using a mobile application as complaint
management increases citizens’ participation and interaction by providing real time information
to government officials on the move.

Therefore this project aims to design and implement Mobile based integrative compliant
management system for Debre Berhan University.

Hence developing a systematic approach to manage those complains successfully, there is a need
to computerize the manual system.

1
1.2 Background of Debre Berhan University
Debre Berhan University, which is a 10 year young university, is established in the 600 years
old historical town- Debre Berhan – a town situated in Amhara Region, North Shoa zone, 130
km away from Addis Ababa in the north. The most powerful explanation of the establishment of
the University is the government`s commitment towards the expansion of quality higher
education as well as ensuring a reasonable distribution of higher education in the country.

Based on these organizing explanations the foundation stone was laid down on 9th May, 2005
G.C by her Excellency w/ro Genet Zewdie, the Ministry of Minister of Education of the Federal
Democratic Republic of Ethiopia.

Then after, the construction of the university was started on a total land area of 102 hectares
which was given by the City Administration of Debre Berhan Town.

1.2.1 Vision

Solves the problem of complaint complexity by providing mobile based service for the
customers from anywhere and anytime.

1.2.2 Mission

 Customers can submit their complaint with their smart phone, desktop, laptop etc.

 They also get decision timely.

 To design and implement application system for proper implementation of the complaint
management system.

1.3 Background of the project

An academic growth can be of various concerns in academic environment to promote social and
functioning educational system. Recently introduced mobile Internet and related technology are
among the most advanced delivery channels that are leading to a new era of mobile government
services and business models. For an effective educational system to take place there are some
issues in academic environment that should properly address to, take for instance issue of
complaints management system in the university. This issue had created a lot of problems for an
academic growth in the various aspects of the educational system. To support this approach, this
project identifies a range of options that can be used to manage and resolve Academic

2
complaints. This includes, where the opportunity presents itself, the need for administrator to
make every effort to resolve potential or actual academic complaints

1.4 Problem description

1.4.1 Statement of the problem

These days the Ethiopian government Ministry of Communication and Information Technology
(MCIT) implementing different e-government services projects [3]. But there is no complaint
logging service available in the portal, it provides a form for feedback which is not complaint.

The current complaint registration system is time taking and inconvenient for the complainant.

Anyone who wants to register complaint should visit in person one of the offices found in the
required office. Because of this constraint, those who do not have time to go to one of the offices
have no alternative way to report about the problem. On the other hand, those who fears to report
thinking something wrong might happen to them do not have other means to place their
complaint.

The other problem seen is related with officers who assigned to collect complaint from public.
They “waste” their time in doing something that does not add value to provide a solution for the
problem. They verify complaint form received from complainant, forward it to respective
department, track the status of the complaint and inform the result to the complainant. Much time
is wasted during this process.

Also there is no any form of application system that used to help for customers to process their
complaint from everywhere and every time with their mobile devices. So that it becomes
necessary for user to have desktop or laptop for using the system and making their complaint
suitably.[7].

However, the compliance process is one sight of the university to achieve the customer
satisfaction.

Specifically the existing system of the compliance process in Debre Berhan University has the
following problems.

The current system faces many problems as it uses manual work for the mentioned activities. In
view of this fact, the team suggests to change the manual system into computerized system

3
  The most type of complains are not well organized and measurable. Since the complaint
processing system is manual and there is no specific rule.
 Deprived customer satisfaction because of the manual based service and it takes time to
provide the system less responsive to make self-assessment over customer satisfaction
 When the customers explain their complaint to the grievance handling office physically
they may fear than sending their complain by writing.
 As the complaint is accepted from the customer it is documented manually.
 Security is very low.
 Finding and retrieving data are difficult.

1.5 Team composition

Name Id number Responsibility

Solomon Mihretie 140/06 Requirement gathering

and analysis

Ashenafi Fikru 114/06 System analysis

Tenaw Tagele 145/06 System design

Miftah Mohammod 135/06 Implementation

Mihret Kefyalew 136/06 testing

Table 1 Team composition

1.6 Objective of the project

1.6.1 General Objective
 To Design and implement Mobile based Integrative compliant management system for
Debre Berhan university.

1.6.2 Specific Objective

 to review the related compliant management system

 to design the integrative compliant management system
 to analysis the most frequently type of compliant.

4
  to organize and create suitable conditions for public complaints.
 to make the system support both English and Amharic languages.
 to implement and test the system based on the specified requirements
 To develop good security mechanism with handling grievance office and user.
 Identify functional and non-functional requirements for the new systems
 Identifying problems of the Existing System.
 Improving current complaint report system.
 Transfer reliable, accurate, and real-time information

1.7 Scope and limitation of the project

1.7.1 Scope of the project

 Facilitate timely management decision making.

 The students can offered their feedback by selecting the teacher and their school
 The department head, HRM, Finance Directorate, Academic record directorate
and the teacher can view the feedback that comes from the user.

 Customer can register, view, search complaints and send request to handling
grievance office.

 Organ of the complaints can view the complaint information

 The students can offered their feedback by either Amharic or English language
 The system uses SMS message communicate officers with user.
 The system can be responsive in different devices

1.7.2 Limitation of the project

 Customer is required to have basic computer skill to use the system.

 The system will not accept the customer speech and image

1.8 Significance of the project

The significance of this study is to serve better than the existing system which is highly manual
and therefore difficult in terms of monitoring the complaint in the University, improve database
and enhance effectiveness, efficiency and security of the system. It is also intended that the study
5
will help in the development of a new and hopefully and standard better computer aided
system.

The system is expected to be easy as user can browse their complaint anytime, staff and
management also can equally response to customer’s complaint in a more easy way.

Generally this system provides the following significances to the system users
 To simplify the compliance process to be easy
 Anyone can send his/her complaint from anywhere and anytime using his smart phone.
 Reduce the paper work
 Protecting corruption and promoting good governance
 The customer can offer their feedback without fears
 To reduce the unwanted communication from customers
 Customers use time effectively.
 To give customer and students satisfaction.
 Faster decision making due to the report generation functionality.
 Creates Job satisfaction to the employees.

1.9 Target beneficiaries of the system

The main users or actors role played in this system are customers from any where or any people
from internal and foreign countries .Also the system give service for all members of the Debre
Berhan University.

1.10 Methodology

A methodology is a set of methods, processes, and practices that are repeatedly carried out to
perform the project. In order to accomplish the objectives of the project, necessary data were
collected and appropriate programming tools and techniques were used. This part deals about
the method of data collection, source of data, and how the data organized and analyzed.

Next, the methods used in the project are described.

1.10.1 Data collection methodology

There were a number of data collection methods. From these methods to do our project we used
observation, interview and document analysis method.

6
1.10.2 Interview technique

We interviews members of the association from their office, and members from their work place.
Like:-

What kind of system the organization has used?

How the existing system works?

What is the duty of the institution workers?

What are the problems of the existing system?

1.10.3 Document analysis

By reading the document which is prepared by the institution that explains about the institution
feature from start date up to current situation.

1.10.4 Observation

We use this method to get the right information about the organization and also to understand
how the existing system works .To gathering data by watching behaviors, events, or nothing
physical characteristics in their physical setting. It is also a habit of to spend day or to with direct
user simply to sit and observe what they do.

1.11 System analysis and design methodology

System development methodology refers to the frame work that is used to structure plan and
control the flow of developing an information system there are different system development
methodologies that are suitable for different projects based on the values technical
organizational project and team consideration. For this project the team used object oriented
software development methodology

1.11.1 Hardware and software Requirements

There are system requirements for developed any kind of application. We use different type
of software and hardware to develop our project. This requirement is like hardware and
software.

7
 1.11.1.1 Software requirement and Database tool

Since, there are many software tools for developing our projects. This system or project uses
listed below.

• Object oriented approach was used as a main approach for this project.
• This project uses eclipse or android studio to write xml and java codes.
• Notepad++ to write php, JavaScript, css and html codes.
• Microsoft office word to write the documentation part.
• E-drawmax to draw diagrams.
• Microsoft power point for presentation slides.
• Enterprise architect

1.11.1.2 Hardware requirement

The software which we develop requires the following minimum hardware configuration:
• computer

• CD drive and monitor.

• Flash.

• Printer.

1.12 CASE (Computer-Aided Software Engineering) tools

Since we integrate two languages that is php and android the tools we help to design the system are:

Activities Tools/programs

Xml layout eclipse

Web server Apache Xampp

Server side scripting PHP

Database server My SQL

Client side scripting HTML

Table 2 CASE (Computer-Aided Software Engineering) tools

8
Since the system is developed for mobile application it runs on both smart phone and computer.
These create suitable condition for users since they simply use their smart phone by installing the
application on android supporting phone.

1.13 Requirement structuring and data modeling tools

1.14 Feasibility study

It is an analysis of the ability to complete a project successfully, taking into account legal,
economic, technological, scheduling and other factors. Rather than just diving into a project and
hoping for the best, a feasibility study allows project managers to investigate the possible
negative and positive outcomes of a project before investing too much time and money.

1.14.1 Operational Feasibility

Proposed applications are beneficial only if they can be turned into user friendly that meet the
users’ requirements. Simply stated, this test of feasibility asks if the application will be worked
when it is developed. Therefore, the system will be designed to be operationally feasible. That
means, the system will operate without failure. Because of it is simplicity and easy access. In
addition to this the system is practical, applicable and also the system operation is easy for the
users. The new system that we develop require organization end user potential and skilled man
power ,also social acceptability that the system completely changed from manual system to
computerized due to this potential and skilled man power of the our team to operate the system is
operationally feasible.

1.14.2 Technical feasibility

The technical feasibility in the proposed system deals with the technology used in the system. It
deals with the hardware and software used in the system whether they are of latest technology or
not. It happens that after a system is prepared a new technology arises and the user wants the
system based on that technology.

1.14.3 Economic Feasibility

The project is economically feasibility attempts to weight the costs of developing and
implementing a new system, against the benefits that would occur from having the new system in

9
place or the cost of developing and implementing a new system less than the cost that finding
benefit from the developed system.

Tangible Benefits of proposed system

• Cost reduction and/or avoidance

• Error reduction

• Increased flexibility

• Increase the speed of activities

• Improvement of management planning and control.

• Reduction in material consumption

Intangible Benefits of the proposed system

• More timely information

• Faster decision making

• improving employee morale

• Increase accuracy

1.14.4 Legal feasibility

The proposed system not conflicts with legal requirements, the government/ company. It meet to
the rule and regulations of the organization or the university or it is not conflict to each other.

1.15 Project schedule work break down structure

We have done and will do all the tasks in this project according to a prescheduled plan specified
the following WBS

10
Task to be Time given for the task
performed
oct nov dec jan feb mar apr may jun

W W W W W W W W WW W W WW W W WW WWW W W W W WWWW W W WWWW W

e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e
e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e e
k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

Selecting the
title

Understanding
the existing
system

Requirement
gathering and
analysis

Analysis, system
and Interface
design

Implementation

Testing

Table 3 Project schedule Work Breakdown structure

11
 1.16 Cost Breakdown structure of the project

In order to achieve the intended goal, the group needs the following materials.

No Name of quantity Unit Price Total price

material (ETB) (ETB)

1 Pen 4 4.50 18.00

2 Paper 100 0.25 25.00

3 CD 2 7.00 14.00

4 Print 200 1.00 200.00

5 Flash Disk 2 90.00 180.00

Miscellaneous 200.00
Expense

Total 637.00

Table 4 Cost Breakdown structure of the project

12
 CHAPTER TWO
DESCRIPTION OF THE EXISTING SYSTEM
2 Introduction of existing system
Whenever a customer of the University requires service from the office he/she required moving
to the University and then he/she required to present the compliant to the handling grievance
officer. In the current system complains written in paper and will be presented to the grievance
handling officers. Then the manager will look after it and then he /she will take care about the
customer’s problems. After that the manager will enquire and allocate the problem to the
specified person in that office.

The current system is time taking, unqualified, costly and not satisfactory since the system is not
computerized system for complaint purpose. Employee/admin spend much time to work its own
activity due to all information is transferred manually by paper-based method and difficult to
register new customer, customer must physically join to the office to get service, difficult to
manage compliant information. So this system consumes time and money.

In the existing system to Compliant Management System details or in the document or the user
should use much time to face his complain to the grievance handling officers. And even for
simple information the user should visit the required office to explain his issue because of the
unavailability of mobile based application system currently in Debre berhan University. In this
section, the organization of the university work principle and the overall system is discussed.
Some defects in the existing system are accordance with:

 Performance.
To give real time complains related solution to the users, current system does not perform
quick response.
 Security:
 Since the existing system is paper based it has less security management system.
 Service:
 Current system cannot give the information quickly because offices notice the
report on the bulletin board rather than using computerized system.

13
  Customers cannot use mobile based application system to explain their
problem.

 Control:
 Wastage of time when testing labor by manual method.

2.1 Player in the existing system

Debreberhan university compliant management institutions have many users that are
participating in the existing system. These are:-

User: A user is a citizen who is interested to forward his/her complaint to office workers of the
university and follow the decision process.
Officer: An authorized employee of the University who solves all the complaints received form
the Users and forwards the complaints response back to the users. The employees who perform
this task are:
 Human Resource Management (HRM)
 Academic record directorate
 Finance Directorate
 College Dean
 Department head
Administrator: Administrator is a person who is responsible to control overall activity of the
system.

2.2 Major Functions in the Existing System

Accepting complaint: Receive the user complain through oral speech and application form.

Solving complaint: Addressing of complaint problem procedure in the existing system is

different. The complaint solving process takes place by keeping its hierarchy .For instance if the
complaint is simple it directly solved orally in short time otherwise it takes long period of time
and continues to the end of the institution organ (from the lowest level to the highest).

Generating report: since the existing system is manual, the report is informed on the notice
board or directly by physical contact with the user.

14
 2.3 Business rules

In every organizations or institution’s there are rules and policies , which used to govern all
activities in specified work flow, control the work flow, and performed in the work environment
this are business rules. Or business rule are statement about the organization’s way of doing
business. So the complaint management in Debre Berhan University governs and controls the
work flow through the following rules.

Identifier Username
Description

BR1 teacher  Work harmoniously with students.

 Work fairly any activities between students
without any discrimination.
 Evaluate students based on the rules and
guide lines of the department.
 Solve the student complain based on evidence
among students.
 Transfer complaints to the next higher body if
he cannot solve it.
•

BR2 user  Users must assign the complaint for the target officer
 The customer should fill the petition form and
personal data clearly and face to the transfer
officer.
 Users must follow the sequence of steps to get
solution for their complain starting from the
lowest one.
 The member of the institution can get complain

15
 more than one times, if it is necessarily
 Users of the system contact with the office
workers to follow their complain procedure.
 Users see the complaint decision on the notice
board or by direct physical communication
 The customer must have complaint before
register the organ of the complaint/handling
grievance office.
 When members or users get in to the organization
to get service they must first registered to the
institution.

BR3 Department Head  Receive the user complain through oral speech
and solve the problem based on complain solving
principles. DC committee in the department head
solve the user complain and forward it to college
dean if it is beyond its capacity.
 Department head should replay the decision to
users
 Department head should write and post notice
for the customer complains

BR4 College Dean  Accept request from the department head or

directly from customers
 Solve the complaint by AC committee .The
decision process is based on rules of the college
or it supports by witness (watcher of the evidence
case of the problem).
 College Dean directly accepted some complaints
to it if the case is for them.

16
  If the user does not satisfied by the decision of
their Complaint College Dean give freedom to
ask to the next branch of officer.
 They post report on the notice board.

BR5 Human Resource  To solve customer notification the complaint

Management solve based on order of sequence.
(HRM)  Access of information depends on the authority
of the user.
 The transfer officer views the data by finding the
customer’s complaint document.
Give employee yearly okay by selecting from
personal fold away (document).
 When the vacant position is announced to
external applicant on notice board on mass media
applicants record most of the time only for
consecutive 6 work days.
 Manage employees of the organization dismiss
from the university if they not properly work
their task in 10 days.
 They should give different information for
employee customer.

BR6 Academic  Students who come late cannot registered or they

record directorate should punished by money.
 An academic record directorate sends form to
colleges and schedules the semester plane.
 Academic record directorate store student grade
online correctly.
 Academic record directorate should modify
student’s grade if it incorrectly send to the

17
 system.

BR7 Finance  To get immediate response users should

Directorate face their complain to employee who give
that service
 If users not satisfied by the response they
can ask the next directorate officer.
 Also if the next directorate officer not
satisfied his/her complaint users has right
to continue until the final stage
(President).
 Officers should clearly announce the
service standard.
 They should get to office on time at work
time
 Office workers should give fair decision
for complain.

Table 5 Business rules

2.4 Report generation for the existing system

The major report generation mechanism in the Compliant Management System for Debre Berhan
University is posting notice on the bulletin board manually.

2.5 Forms and other documents of existing system

There are a number of forms and documents which are used by the existing system. The forms
are used during the period of accepting and solving process for the employee to control business
rules of the system. The uses of these forms are to assure the correctness of their activity and to
generate reports. The following is sample form taken from Finance Directorate.

18
19
 2.6 Bottlenecks of the existing system
Grievance handling officers decide the decision by wasting much time and wasting high labor force. Also
customers cannot get quick decision.

In case of performance of the existing system the condition is manual so customers or applicants
contact physically with the officers in order to face their complaint.

The basic bottlenecks of existing system are:

 The process is tedious for officers and users.

 Those who do not have time to go to one of the offices have no alternative way to report
about their problem.
 Customers who fears to report thinking something wrong might happen to them do not
have other means to place their complaint.
 Report generation in general is very difficult in current system.
 Much of the current system of the Compliant Management System is done heavily in
human interaction with the officers.

2.7 Practice to be presented

 To solve complaint the officers have their own rules and standards written in document
form for complaint user.
 The complaint decision is announced to user on notice board.
 To face complaint users bring a applicants letter from anywhere physically to officers.
 Officers allow to access information about the authority of the user.
 The employee of officers must have full reason to solve their complain.
 If the user wants to face their complain different reason first they must apply to the
lowest level and then continue to next branch of office such as department head ,college
dean ,HRM, Finance Directorate, and etc.
 If one wants to leave from DBU before he/she fills the form leave form he/she must
return all working material to respected department otherwise they will be rejected.

20
2.8 Proposed solution for the new system
To improve the current complaint handling system for the University, we have proposed mobile
based complaint management system. The system simplifies registration process of Complaints.
The system enables users of the system to register complaints by sending SMS message to the
system. Users can follow status of the registered complaint using SMS. Complaint information
provided to the public through application system in an effort to better share data about
complaint. The proposed system of this project intends to design and implement Mobile based
integrative compliant management system for Debre Berhan University. This system designed to
create alternative way of complain management system for the university. It reduce burden for
the grievance handling office and any customers simply use the system from anywhere at any
time.

 The registered complaint automatically forwarded to the office in charge of handling the
issue. This will reduce time needed to process and provide a solution for complaint.
 Provide a very good and fast service for the users by computerized system.
 The system that are developed solves the problems appear in the current system.
 The new system enables users to register compliant information.
 to view users notification, and officers to replay solution to submitted customer post
notice to customer, allows coordination among workers, allows authorized users to access
the system .
 The new system increases the security, availability and performance of the system.
In this system user can easily register complain by sitting at his/her computer or
smart phone using the system, rather than going to office .

2.9 System Requirement Specifications

Requirement specifications develops a recommended process improvement action which can

include quick fix for serious problem, modification of existing manual systems or the initiation
of the a organization re-engineering process. There are two main types of system requirement
specification this are functional and non- functional requirement. Functional requirements are
function that the system undertakes, whereas non-functional requirement are restrictions that the
system consider.

21
2.9.1 Functional requirement

The functional requirements are concerned with the actual performance of the system that is
going to be developed. Functional requirements describe the functionality or service provided by
the new system:

 The system is capable of request complain to handling grievance office.

 The system capable Recording new complaint and complain information to the database
in the main process of the system.

 Allow registering complaints by sending SMS text,

 Enabling the users to take or get the registered complain that they registered orderly.
 Document the file which is placed on the system of the data base to be accessed as registers
information.
 Allow workers to view registered complaints to update the status of the complaint.
 It organizes and makes searchable sites.
 The system generates a report: Allow to generating different types of reports which
include types of complaints registered on specific date, month or year, viewing
summarized report.
 Allow the administrator to manage access to the system.

2.9.2 Non-functional requirements

Non-functional requirement is a requirement that specifies criteria that can be used to judge the
operation of a system.

Non-functional requirements place constraints on how the system will do so. The non-functional
requirement elaborates a performance characteristic of the system. Also these requirements relate
to system attributes such as reliability and response time and they can arise due to user
requirements. Any requirement which specifies how the system performs a certain function
considered when designing the solution.

The following are non-functional requirement associated with the system:-

• Performance:-The system error free when accessing huge amount of data. And the
system should be accessed by many users and should have fast response time.

22
 • User interface:-The system user friendly. The developed system provide mobile based
application user interface and are compatible with browsers like internet explorer,
Mozilla Firefox, Google chrome. Users can have access to the system from anywhere
using their desktop or mobile phones. We should make the system simple and easy to
understand and to interact with. It should be easy and painless for the user to register and
view information user can understand the system either by English or Amharic (local)
languages.

• Resources:- the system is compatible with the specified hard ware and software
requirement and the system should have compatible with any environment.

The system is usable to anyone who have skill of English and Amharic language.

The capacity to retrieve data from the stored data base

Technical Requirements

A technical requirement pertains to the technical aspect that your system must fulfill ,such as
performance related issue ,reliability issues, and availability issues, and many technical
requirements can actually be thought of as constraints, and in fact constraints can apply to either
technical or business issues. Some of the technical requirements of the compliant management
system are:-

• Scalability:-The ability to add capacity (and users) to a deployed system over time.
Scalability typically involves adding resources to the system but should not require
changes to the deployment architecture.

• Availability:-The system to be available 7 days a week and 24 hours a day. And A

measure of how often a system’s resources and services are accessible to end users, often
expressed as the uptime of a system

• Performance:-The systems have high performance and error free and the measurement of
response time and latency with respect to user load conditions. As the system is a mobile
based system, it can be accessed by many users simultaneously. So, the system should be
capable of handling as many users as possible while maintaining the performance of the
system.

23
  Security:-A complex combination of factors that describe the integrity of a
system and its users. Security includes authentication and authorization of users as well
as secures compliant information. The system shall ensue that data is protected from
unauthorized access. Any user who wants to login to the system must identify themselves
using a login name and password. Only users who are authorized in this way may access
protected data. A user in any section will be given the right to access and/or modify the
data related to that section. In addition, the system allows only one user to use a single
user name at a time. Generally, the system should be secure to a level that, even when it
is available online, critical information should not be available to non-authorized users.
 Error Handling

The system is expected to handle errors while input. The system validates data entry for
correctness. Errors that occurred from the wrong doing of users will be handled by appropriate
exception handling mechanisms. If an error occurs, for instance if required fields missed while
the user submit complaint using website, the system will identify the error and notify the user so
that he/she can take the appropriate corrections.

• System Modifications
Over time the system can be enhanced with additional features like including customer speech
and image messages, therefore the application is designed in such a way that whenever any
change is initiated to easily incorporate with the system.

24
 CHAPTER THREE

3 SYSTEM ANALYSIS
This chapter contains and describes about Use case diagram, use case description, and Analysis
Model (Activity diagram and Sequence Diagram) and modeled using unified modeling language
(UML) models.

3.1 System models

• Use case identification and their detail description.

• Actor list

• sequence diagram

• Analysis class diagram.

• Activity diagram for each activities in the compliant system

 Actor and use case identification

Use case is a list of steps, typically defining interaction between a role of actor and a system to
achieve a goal.

• The actor can be a human or an external system.

• The use case made up of a set of possible sequence of interaction between systems and
users in a particular

3.1.1 Scenarios
In the complaint management system the actors and functional requirements interact with use
case models. Use case diagram shows over all activities of the system digramaticaly.

Actor of the system

 Officers such as

• System administrator

25
 • Grievance handling officer

• Department head

• Human resource management officer

• Collage dean

• Finance Directorate

 Users

• Use case

• Login

• Register complain

• Modify complain

• +View notification

• View private and public complain

• View compliant person

• View and replay complain

• Create account

• Send complain

• Manage account

• Add user

• Send decision

• View and replay feedback

26
 • Send feedback

Figure 1 Use case diagram for compliant management system

27
3.1.2 Use case description
Use case name Login
Use case ID UC1
Actors System administrator, Handling grievance office, Users ,Department
head, Human resource management system, Collage dean, Office
manager, Finance Directorate,

Description Users are authenticated and taken to their own

user interface
Pre-conditions Users have username and password
Post-conditions User is authenticated and taken to his/her own user interface
Basic course of action User action System response

1. The user opens the main 2.the system display the Main
home page Home page
3.The user inputs user name and 4. The system validates the account
password and submits System and displays the user Require
Response information.
5.use case ends

Alternate course of action A login name or password is invalid

A 4.The system displays invalid user name or
password message
A 5.The user reenters the user name and
password
A 6.The use case continues from step 3
actors may Change password

Table 6 use case description to Login

28
 Use case name Register complain

Use case ID Uc2

Actor User

Description The user can register complain to handling grievance office

Precondition There should be fill available information on the compliant registration

page

Post condition The system can register complain information

Basic course of action User action System response

2. The System displays the register

1. The user register
complain information Page.
compliant page
4.The System displays a success
3. The user fills the Necessary
message
information and Submit the
forms. 5 .Use Case Ends

Alternative course of If the submitted form is not filled completely or invalid.

action
The system displays “unsuccessful” message

The user fills the missing information and corrects invalid inputs

The use case continues login page

Table 7 use case description to register complaint

29
 Use case name Manage account

Use case ID UC3

Actor Administrator system
Description The listed actors may be update their account.
Precondition They must be first registered in to the database.
post condition updating their account in the system
Basic course of action User action System response
User Action 1. The actor fills the 2.The System displays the edit
necessary information and profile Page
Submit 4.The System displays a success
the forms message
5.Use Case Ends
Alternate course of action A: If the submitted form is not filled completely or invalid.
A4.The system displays “unsuccessful” message
A5.The actor fills the missing information and corrects
invalid inputs
A6.The use case continues from step 4
Table 8 Use case description for update account

30
 Use case name View notification
Use case ID UC4
Actors Users ,Department head, Human resource management
system, Collage dean, Office manager, Finance Directorate
Description User and organ of the compliant ask/post their difficult
complain to the handling grievance office
Pre-condition Actors registered complain first.
Post condition User action System response
1.The user invoke on view 2.The System displays the view
notification page notification Page
3. The user fills the 4.The System displays
necessary information and notification page
Submit the forms. 5.Use Case Ends

Basic course of action User and organ of the compliant put the content of the
question in the available input box.
Table 9 Use case description for view notification
Use case name send decision
Use case ID UC5
Actors Department head, Human resource management system, Collage
dean, Office manager, Finance Directorate
Description Those actors submits their complain resolution to their user and
organ of the compliant after completed.
Pre-condition • handling grievance office login first
• must do their solution
Post condition • Send their resolution to the owner of the complaint.
Basic course of action 1. The handling grievance office opens the home page.

2. click on send menu

3. Fill the information on the label.

4. Click at send button

31
Table 10 Use case description for send Decision

Use case name Send Feedback

Use case ID Uc6

Actor User

Description This actor’s send feedback to the handling grievance office

Precondition The listed actors interact (open) with the home page of the system.

post condition The listed actors send important feedbacks to the handling
grievance office

Basic course of action 1. The listed actor opens the home page.

2. click on feedback menu

3. Fill the information on the label.

4. Click at send button.

Alternate course of action If there is no feedback the system displays no feedback is posted

Table 11 use case description for send feedback

Use case name View feedback

Use case ID UC7
Actor Department head, Human resource management system, Collage
dean, Office manager, Finance Directorate
Description The listed actors view feedbacks sent by users.
Precondition The actors should interact with system
Post conditions The actors successfully watch feedbacks
Basic course of action •Actors click on view feedback icon
•The system makes display feedback
Alternate course of action The actor may replay feedback
Table 12 Use case Description for View feedback

32
Use case Name Search

Use case ID UC8

Participating Actors Users ,Department head, Human resource

management system, Collage dean, Office
manager and Finance Directorate

Description Allows getting detail information of registered

complaints.

Entry Condition No

Flow of Events 1. The user access the system hosting the

application.

2. The user selects search criteria.

3. The user presses submit button.

4. The system displays detail information

based on criteria.

Exit Condition Detail information of the complaints viewed by

the user.

Table 13 Use Case Description for Search

33
Use case Name Logout

Use case ID UC9

Participating Actors Department head, Human resource

management, Collage dean, Office manager
and Finance Directorate

Description After using the system, The user should be logged out from the system

Entry Condition The user is already logged in.

Flow of Events 1. The user presses “Logout”.

2. The system will go back to home page.

Exit Condition The user is logged out.

Table 14 Use Case Description for Logout

Use case Name Change Password

Use case ID UC10

Participating Actors Department head, Human resource

management, Collage dean, Office manager
and Finance Directorate

Description Once the user obtains account, can change

his/her password.

Entry Condition User already logged in.

34
Flow of Events 1. The user selects “Change password” Button.

2. User is prompted for user name and old

password, new password and confirmation of
new password.

3. The user enters the user name, old and new

password and submits to the system. (….A1)

4. System does the authentication. 5. The

system displays an acknowledgment.

A1 Authorization fails

1. If the old password is invalid, the system

informs that

user has entered wrong password or if the new

password does not match with confirmation

password, the system displays error message
and allows reentering of the attributes.

2. Go to step 2.

Exit Condition Password is changed.

Table 15 Use Case Description for Change Password

35
Use case Name Add User

Use case ID UC11

Participating Actors Administrator

Description The administrator adds user name and password

to database to create new user.

Entry Condition User with administrator privilege logged in to

the system.

Flow of Events 1. The administrator selects “Add User” link.

2. The system displays add user form.

3. The administrator enters user name, password,

Conformation password, worker name and

position.

4. The administrator clicks “Submit” link.

5. System does the validation. A2

6. The system displays acknowledgment

message.

36
 A2 1. The system displays error message if required
fields missed or the newly created account name
already exist in database or if the password does
not match with conformation password or if the
worker has already account.

2. Go to step 3.

Exit Condition New user added to the system.

Table 16 Description of Add User Use Case

Use Case Name Generate Report

Use case ID UC12

Participating Actors Department head, Human resource management, Collage

dean, Office manager and Finance Directorate

Description This use case describes the event of creating a report

based on the information collected by the system.

Entry Condition The administrator is logged on

Flow of Events 1. The use case activated when the administrator selects

“Report”.

2. The system displays “View Report Page”.

37
 3. The user enters report criteria from drop down menu.

4. The system generates report based on the criteria.

Exit Condition Report from database is generated and the user view or
print the report.

Table 17 Use Case Description for Generate Report

3.1.3 Object model

Object diagram on the other hand is a graph of instances, including objects and data values. A static
object diagram is an instance of a class diagram. It shows a snapshot of the detailed state of a system at a
point in time. The use of object diagrams is fairly limited, mainly to show examples of data structures.

3.1.3.1 Data dictionary

Class name Attribute

College Dean Id, First name ,Last name, address ,Sex, case
problem

Human Resource Management Id, First name ,Last name, address, Sex case
problem

Department Head Id, First name ,Last name, address, Sex

Academic Record Directorate Id, First name ,Last name, address, Sex case
problem

Finance Directorate Id, First name ,Last name, address, Sex case
problem

Administrator Id, First name ,Last name, address, Sex case

problem

38
Other Grievance Handling Officers Id, First name ,Last name, address, Sex case
problem

Users Id, First name ,Last name, address, Sex case

problem

Table 18 Data dictionary

3.1.3.2 Analysis level class diagram (Conceptual Modeling)

Class diagram is a graph of classifier elements connected by their various static relationships.

UML class diagrams show the classes of the system, their inter-relationships, and the operations
and attributes of the classes. Class diagrams are typically used, although not all at once, to:

• Explore domain concepts in the form of a domain model

• Analyze requirements in the form of a conceptual/analysis model

• Depict the detailed design of object-oriented or object-based software

Class diagram is unified modeling language (UML) is a type of static structure diagram that describe the
structure of the system that showing:

• Entity

• Their attribute

• Operation (or method’s)

• And the relationship among the class

39
Figure 2 analysis class diagram

3.2 Dynamic model

3.2.1 Sequence diagram
Sequence diagram showing the sequence of interactions among objects and used to represent or
model the flow of messages, events and actions between the objects or components of a system.

40
Figure 3 Sequence diagram for create and update account

41
Figure 4 Sequence diagram for view complaint

42
Figure 5 Sequence diagram for handling grievance office send solution to User

43
Figure 6 sequence diagram for login

44
3.2.2 Activity diagram
It represents the flow from one activity to another activity.
Activity diagrams model is a high level business or processes or transitions between states of a
class. In this activity diagram tried to document the flow of logic for the major business
processes.

Log in to the system

Figure 7 Activity diagram for login

45
Figure 8 Activity diagram to manage account

46
Figure 9 Activity diagram for handling Grievance office, user and organ of the compliant view notification

47
Figure 10 Activity diagram for User compliant registration

48
Figure 11 Activity diagram for handling grievance office send solution

3.2.3 State diagram

The state diagram shows the sequence of states that an object goes through the events that cause
the transition from one state to the other and the actions that result from a state change.

49
Figure 12 State diagram for send complaint

50
 Figure 13 State diagram for Registration

Figure 14 state diagram for login

51
3.2.4 User Interface prototype (Navigational paths and screen mock-ups)
Prototype interface since the project design is implemented using both android studio and php languages
the graphical interface which displayed first when the system executed is the home page. In the home
page every activity is performed by using corresponding buttons of the form.

To use the system the user

 Run the project on mobile device and display the home page.
 Click the registration button to send SMS of their complain
 Click view complain solution button to see the solution of the response
 For officers or such as HRM, Academic record directorate, Finance Directorate, Department
Head College Dean and other Grievance Handling office the user login to the system and then do
any activities in the corresponding names of the home button

Figure 15 user interface prototype

52
3.2.5 Supplementary Specifications
Business Rule for the new system

Name: Determine eligibility to login

Identifier: BR1

Description: the complaint should be solved only by authorized persons, since there is secrete
issues that should not be altered by anybody.

Name: The user should have to fill all necessary information to be registered and to submit the
complaint to the system.

Identifier: BR2

Description: during registration the customer should fill all required information in order to be
registered and to get service.

Name: record may not be repeatedly stored

Identifier: BR3

Description: for the removal of data redundancy which leads to wastage of storage memory, it is
necessary to remove redundancy whenever necessary.

Name: field emptiness

Identifier:-BR 4

Description:-it is not allowed to leave a field empty before performing any operation.

53
 CHAPTER FOUR
4 SYSTEM DESIGN
4.1 Introduction

The Design Phase seeks to develop detailed specifications that emphasize the physical solution
to the user's information technology needs. The system requirements and logical description of
the entities, relationships, and attributes of the data that were documented during the
Requirements Analysis Phase are further refined and allocated into system and database design
specifications that are organized in a way suitable for implementation within the constraints of a
physical environment. (e.g., like computer, database, facilities etc).

A formal review of the high-level architectural design is conducted prior to detailed design of the
automated system/application to achieve confidence that the design satisfies the system
requirements, is in conformance with the enterprise architecture and prescribed design standards.
To raise and resolve any critical technical and/or project-related issues, and to identify and
mitigate project, technical, security, and/or business risks affecting continued detailed design and
subsequent lifecycle activities.

During the Design Phase, the initial strategy for any necessary training is also begun. Estimates
of project expenses are updated to reflect actual costs and estimates for future phases. In
addition, the work planned for future phases is redefined, if necessary, based on information
acquired during the Design Phase.

4.1.1 Purpose of the system

The purpose of the Software Design Document is to provide a description of the design of a
Compliant Management System fully enough to allow for us to proceed with an understanding of
how this system is developed. The Software Design Document provides information necessary to
provide description of the details for the software and system to be built.

4.1.2 Design Goal

The design goals represent the desired qualities of the system and provide a consistent set of
criteria that must be considered when making design decisions. Design goals of the system are
presented as follows.

54
End user criteria: This project is very simple to use. Anyone who can read English or Amharic
can use the system, because, to use the system only clicking a button, it does not need to write
commands and to think how to use it. This program will have a well-defined and easily
understood interface. The processes will be easy to understand and use by a user of any level.
 User Interface: User interface of the system should be attractive and simple since the system
supports both Amharic and English languages so that the user of the system will easily interact
with the system. No technical jargon is to be presented to the user at any time. The interface must
be designed taking into consideration those who do not work with computers on a day-to-day
basis.

 Documentation: A document which contains all features of the system should be provided for
the users of the system.

 Performance: The system will complete the task quickly to allow easy input of data and to
retrieve data from the server. The system will be accessible from any computer and will be
accessible anytime a user would want to use the program. The system serves a number of users
which are expected to access it concurrently.

 Robustness: The system should be designed in such a way that users cannot proceed having
entered invalid input or data in all cases of interacting with the system.

 Availability: The system should be available 24 hours a day to enable registering complaints
any time convenient for users of the system.

 Security: The system must prevent unauthorized users to access part of the system which is
restricted for authorized users. Authorized users must be provided with user name and password.
It is designed to visit the system for new members when the system is open for guest.. The end
user of the system most of the time will be asked for authorization login except if the system
developer has set its own criteria to access the system.

 Modifiability: Whenever any change needed to be made on the system it should be possible to
easily modify the system. For this purpose, Object Oriented approach should be used so that
modification to some part of the system could not affect other parts

55
.  Portability: - The system should be designed in such a way that users can access the server
side being on various platforms like Android, Windows, UNIX or Macintosh using common
browsers.

4.2 Current software architecture

Since the current system is manual the complaint solution process is paper based there is no any
software architecture to support the system.

4.3 Proposed software architecture

The communication between the client and server is through Http protocol. The second
component of the system is a web server on which an application runs and communicates with
database to provide responses for the user. The third component is mobile user which sends SMS
message to the system. The message sent to the system reaches the system through GSM
network. The system accepts and sends SMS message through GSM mobile attached with the
computer or using GSM modem.

There are three tier architecture for the system

The presentation tier: Clients directly interacted to provide GUI and allow the client gaining
access of the system.

Logical tier (middle tier): acts as bridge between client and server.

Data access tier: supports data persistence mechanism and storage to the data.

The following figure shows the architecture of the system.

56
 Figure 16 State diagram for Registration

4.3.1 Overview
This section describes the requirements of the distinct proposed software architecture.

The system we propose is designed as a collection of services, which uses the Compliant
Management System middleware to communicate with each other. These services can run on
separate hardware Components devices both in mobile and computer. The system under
consideration will have secure managed interfaces or proxies to isolate systems from illegal
access. The system Allow the citizens of Debere Berhan Uinversity direct access to post their
complaint within the overall data systems in simple operation. The components are:

Grievance handling officer, Users, Department head, Human resource management officer

Collage dean, Administrative office manager the functions of the system are almost the same
function mainly accept and solve user complaints.

57
 4.3.2 System decomposition

cmp Complaint Management Subsystem

Complaint Mgmt Subsystem

Account Mgnt Subsystem

View Register
Notification Complaint Manage crate
account account
View And
Replay Update
Complaint Complaint

Complaint Mgmnt System DataBase

Complaint
Management
SubsystemDatabase

Generate Report Subsystem

SMS Application sub system

Recive SMS
SMS Report Report

Send SMS

Figure 17 system decomposition

4.4 Hardware /software mapping

The system has three main components: the desktop client, server and mobile client. User can
access the system through a client. The client component defines users of the system which

58
access the system through Http protocol. The client send request using browser software found
on a client machine and the system responses for request reaches to the system through Internet..

Figure 18 Hardware/Software Mapping

4.4.1 Persistent data management

Complaint Management System has got several objects that need persistence data storage. The
objects have links between them that means they happen to share attributes. Considering the
number of times it is needed to make complex queries on the database, a relational database
system is chosen to effectively manage large dataset the system has to store. The user account
information, which keeps data of the user name, pass keys and user levels, is the one that will
enable the system to provide the access rights according the user level.

59
The relational database design of the system is shown in following figure

4.4.1.1 Mapping
class Mapping

User<table>
User - address(): char
- adress - E_Mail(): char
- email - phone number(): int
- Phone number - sex(): char
- sex - user id(): char(pk)
- user id - user name(): char
- user name
college Dean<table>
College Dean - College id(): char(id)
- college id - College Name(): char
- college name - Department(): char
- Department
Department
Department Head Head<table>
- Dept Id - Dept Id(): char(pk)
- Dept Name - Dept Name(): char

HRM<table>
HRM - Office Id(): char(pk)
- Office ID - Office Number(): int
- Office number - Officer Name(): char
- Officer Name

Acadamic Record
Acadamic Record directorate<table>
directorate
- offfice number(): int
- Office ID - Office id(): char(pk)
- Office Number - Officer name(): char
- Officer name

Finance Directorate<table>
Finance Directorate
- office Name(): char
- Office name: char
- Office number: int(pk) - Office Name(): char
- Office number(): int (pk)
- Officer Name: char

Other Grievance Hndling Other Grievance Hndling

Officer Officer<table>
- Office Name: char - Office Name(): char
- Office number: int(PK) - Office Number(): int(pk)
- Officer Name: char - Officer name(): char

Figure 19 mapping

60
4.4.1.2 Database design
4.4.1.2.1 Physical Database Design

Physical database design translates the logical data model into a set of SQL statements that
define the database. For relational database systems, it is relatively easy to translate from a
logical data model into a physical database.

Rules for translation from logical to physical database design:

 Entities become tables in the physical database.

 Attributes become columns in the physical database. Choose an appropriate data type for
each of the columns.
 Unique identifiers become columns that are not allowed to have NULL values. These are
referred to as primary keys in the physical database. Consider creating a unique index on
the identifiers to enforce uniqueness.
 Relationships are modeled as foreign keys.

Column name Data type Primary ley Foreign key Null able Uniqueness

IDno Varchar(255)  No

Name Varchar(255) No

Fname Varchar(255) No

Age Integer No

Sex Varcher(10) No

Date Varchar(255) No

Address Varchar(255) No

Reciver Varchar(255) No

Status Varchar(255) No

Organ Varchar(255) No

Cause Varchar(255) No

61
Description Varchar(255) No

Evidence Varchar(255)
Table 19 register table

Column Data type Primary key Foreign Null able Uniqueness

key

Messageid Varchar(255)  No

Senderid Varchar(255)  No

Reciverid Varchar(255) No

Subject Varchar(255) No

Content Varchar(255) No

Date Date No
Table 20 message table

Column Data type Primary key Foreign Null able Uniqueness

key

feedbackid Varchar(255)  No

Senderid Varchar(255)  No

Reciverid Varchar(255) No

Subject Varchar(255) No

Content Varchar(255) No

Date Date No

Email Varchar(255) No
Table 21 feedback table

62
Column Data type Primary key Foreign Null able Uniqueness
key

Department Varchar(255)  No
tableid

Department Varchar(255) No
name

College Varchar(255)  no
Table 22 department table

4.5 Logical database Design

The class diagram represents the static view of an application. Class diagram is not only used for
visualizing, describing and documenting different aspects of a system but also for constructing
executable code of the software application. The class diagram describes the attributes and
operations of a class and also the constraints imposed on the system. The classes diagrams are
widely used in the modeling of object oriented systems because they are the only UML diagrams
which can be mapped directly with object oriented languages. The class diagram shows a
collection of classes, interfaces, associations, collaborations and constraints. It is also known as a
structural diagram for this the team developed the following class diagram.

63
Figure 20 Database Design

4.5.1 Access control and security

The essential SMS process is required for the successful operation and management of complaint
activities. One of the processes is access control and security. The Compliant Management
System must establish mutual trust and secure access between the authenticating users,
authorizing access, and enforcing security features. Thus processes establish that a customer and
officer site are who user names and passwords, encryption keys, or digital certificates and
signatures. The compliant management system site must then authorize access to only those parts
of the site that an individual user needs to accomplish his or her particular communications.
Thus, individual usually will be given access to all resources of compliant management system

64
site except for others people’s accounts, restricted the organization data, and webmaster
administration areas.

Department College HRM Academic Finance User Admin

ACTOR head dean Record Directorate

ACTIVITIES officer

Register complaint 

Send complaint 

Replay solution     

View notification      

Generate report 

Create account 

Add user 

Search complaint       

Manage complaint 

Update complaint      

Table 23 Access Control

4.5.2 Global software control

Flow of message between subsystems:
Control flow is distributed within the branches of the university institution grievance handling
officers. Each service has its own control flow of authority to solve the complaint based on its
level of office hierarchy.

• Services request input wait for it and resume control when it arrives.

• There is Service Manager coordinating communication between processes of offices and

balancing needs and abilities between users.

65
• The system use SMS to communicate User and officer with each other.

Concurrent control:
The complaint management system communication between users and balances abilities and
needs of the services for many users at the same time simultaneously.

The service manager also handles asynchronous events within the system.

The officers replay complaint solution to the users by login in to the system for communication
system.

The Complaint management system architecture is to have an explicit, decentralized

software control.

o The complaint officer access the user SMS by gathering information from the
complaint management system.
o The officers replay the user complaint by logging in to the system.
o The users get notification from officers when there is some modification in the
complaint.
o Users simply use the system without any complexity in their own languages
(Amharic or English).

4.5.3 Boundary conditions

The user can access the system from anywhere at any time without boundary. The boundary of
complaint management system is the service is focused only the main components of the offices
found in the university since the organization is very broad it is difficult to include all branches
of the complaint processor institution except the well-known major offices such as Department
head, college Dean, Academic Record Directorate, Finance Directorate and HRM. The
complaint managing principle is mainly focused in SMS application. The Project cannot support
student speech and images.

 Click logout to exit the system and login to open it.

o Validation:

 Logging in:

66
 o Username or password field are greater than 7 in length in order to protect illegal
guess.
o When the username and password much the specified screen display and when
logout the home page does not appear

 User settings
o User is unable to change certain settings or changes not allowed without
password.
 Data Entry
o The system asks to fill the correct information in the required page.
 Communication with SMS
o The communication line with the application system takes place through SMS
notification
o The user selects the required office by dropdown list.
o The system supports either English or Amharic input.

4.6 Subsystem services

As shown in figure 3.3.2 above the system is subdivided in to four sub services. Each of these
components is represented by a subsystem. The system is decomposed in to four subsystems.
Each of these subsystems is described followed by a diagram that shows the decomposition of
the system in to its subsystems and the dependencies among the subsystems.
1. Complaint Management Subsystem Responsibility of this subsystem is to handle
classification of complaints and update of its status.

The functional requirements are:

 Update complaint
 Register complaint
 View and replay complaint
2. SMS Management Subsystem This subsystem is responsible for accepting SMS text
arrived to the system and sending SMS message when new message arrives.

The functional requirements are:

67
  Receive SMS
 Send SMS
SMS report
3. Account Management Subsystem This subsystem is responsible for managing the
creation, modification and deletion of user accounts.
 manage account
 create user account
4. Report Generation Subsystem This subsystem handles the task of generating different
reports based on criteria set by the users.
The functional requirements are:
 Generate report

4.7 Component diagram

By this Diagram, components of the system will be wired showing that there is relation
among components; management of the system, owners, database and operations performed
on databases such security issue. This in some extent shows which component or objects will
be accessed by whom and what type of security infrastructures it is using.

68
Figure 21 component Diagram

4.8 Deployment diagram

Deployment diagram, which consists of nodes and their relationships, is used to visualize the
topology of the physical components of a system where the software components are deployed.
The deployment diagram of Compliant Management System is shown in figure 4.4. Browser
component, in the client node, is responsible for browsing applications which found on a web
server.

A deployment diagram is a graph of nodes connected by communication associations.

 Nodes are shown as 3-D boxes.

 Nodes may contain component instances.

69
  Components may contain objects (indicating that the object is part of the component).

Deployment diagrams are useful for showing a system design after some decisions are
made; these decisions include the following: Subsystem decomposition, Concurrency,
Hardware/Software Mapping

70
Figure 22 Deployment Diagram for compliant management system

71
 5 CHAPTER FIVE
OBJECT DESIGN
5.1 Introduction
In this chapter objects and their relationships of the complaint management system with the
combinations of the class has been shown. It describes object design trade-offs made by
developers, guidelines they followed for subsystem interfaces, the decomposition of subsystems
into packages and classes, and the class interfaces. Complaint management consists of
subsystems or different offices who work separately but they have also common tasks. During
the object design, characteristic of each system must be considered its own and the whole system
must be considered.

5.2 Object design tradeoffs

In our system we can be divided into modules. some module in the university with most of the
functionality that we need, included in it, then the complaint management system can be bring
benefit to save time and human resources. Based on requirements, in the complaint management
system, we can do modules like:

 Show the branches of Debere Berhan offices module

 generating report module
 show complaints with their corresponding offices
 register complaint
 view notification of complaint decision and replay response
 In the object design phase some trade-off decisions may needed to be made:
UNDERSTANDABILITY VS COST
 Understanding Vs. cost is too important during the testing phase of the project. Each form
and code must be readable, so number of codes increase in the system and each must be
implemented in a clear way. Writing comments into the source code increases the
understandability of the code. This causes an additional cost in the developing phase.
SECURITY VERSUS COST
 In Debre Berhan complaint management system, officers have to be authorized to
connect system and see people information users can send complaint to the system even
if they are not authorized, but they must require privilege to view their notification and
decision. Each user will be able to login to the system by using the username, role and
password.

72
5.3 Interface documentation guidelines

The UI, depending on the type of data that the field input validation we use, the numeric or
contain alpha characters. In our SQL database we use, the fields might have a maximum width
value. These make sure there is enough space in each of the fields.
Interface documentation guidelines and coding conventions are the most important factors that
can improve communications between developers during object design.
5.4 Package
Packages in our system are different types of officers and their corresponding functions to
process complaint. Therefore these different classes and interfaces such as officers, users and
their related interactions organized in a package as shown in the figure below.

73
Figure 23 Package

74
 5.5 Class interfaces

Figure 24 Class interfaces

5.6 User interface design

. To interact with the system users will communicate through the following user interface
designs.

Home Page: It is the first page which displayed when the deployed is opened. Users can
perform some activities without login however officers and users cannot accessed information
and contains some links which lead the user to other page according to their privilege if they are
authorized.

75
Figure 25 Home Page

Customer registration page: customers register to the database in order to get complaint
decision.

76
Figure 26 Customer registration page

Complaint registration page: here is one sample user interface among different options available
to send complaint

77
Figure 27 List of complain sent to it department

Complaint view page: there are many offices such as departments, HRM, Finance Directorate,
colleges, and others who accept complaints and replay solution back to sender .here is interface for
Finance Directorate. (beforclicking thelink)

78
Figure 28 Complaint view page

79
Descion paper that wii be sent to the sender

Figure 29 Descion paper that wii be sent to the sender

80
81
Figure 30 Home pages in android to integrate with php

82
 6 CHAPTER SIX
IMPLEMENTATION AND TESTING
6.1 Introduction
In this chapter implementation and operation, physical design specification are converted in to
actual functions, we have tried to correct the code as much as possible until their errors have
been corrected. The system is installed, user sites are prepared for new system and user must
come totally on the new system rather than the existing one to get there work done. There are
some managerial activities in this, coding, testing, and installation.

6.2 Final Testing of the System

Once code has begun, the testing process can begin and proceed in parallel.AS each program
module is produced, it can be tested individually, as part of the larger program, and then as part
of larger system. The following are different testing strategies.

It is the final step of testing in which the a whole with all forms, code, and modules
are tested. In this procedure we have tested all the functionalities of the System. All

errors in the forms, functions, modules have been tested. Finally System testing meets the
desired requirements.

Unit testing: - we have been test the unit producing expected output against the given input.
The objective of unit testing is to: -Check whether the return type of the functions is correct.

 Check if the correct output is produced for different inputs.

 Check the input data that we write on the GUI must be submitted to the data base.
 Check the GUI can access the privileged data from the data base.

Integration testing

By combining each individual form and report with their concerned database us tested by
giving general date. From this the team can understand that how the system work using
the separate module.

Validation Testing or System Testing

83
It is the final step of testing. In this the team members tests the entire system as a whole with all forms,

code, modules. This form of testing is popularly known as Black Box testing or System tests.

Coding
In the coding system we have been turned the designs in to working codes as follows:

Code for login:

<?php

include('connection.php');

//Start session

//session_start();

//Unset the variables stored in session

unset($_SESSION['SESS_MEMBER_ID']);

unset($_SESSION['SESS_FIRST_NAME'])

//Sanitize the POST values

function createRandomPassword() {

$chars =
"abcdefghijkmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";

srand((double)microtime()*1000000);

$i = 0;

$pass = '' ;

while ($i <= 3) {

$num = rand() % 33;

$tmp = substr($chars, $num, 1);

$pass = $pass . $tmp;

84
 $i++;

return $pass;

$confirmation = createRandomPassword();

?>

<form action="index.php" method="post" onsubmit='return formValidation()'>

<table style="border:1px solid black; border-radius:50px;margin-top:15px;box-shadow:8px

15px 8px black;" width="50px" height="313px" align="center">

<tr><td colspan=2 align=right><font color=black><p style="margin-right:3%;"><font color=red

size="2"></font><font face="Times New Roman" color="black"
size="3"></font></td></tr><tr>

<tr>

<td colspan=2 align=center><font face="Times New Roman" color="black" size="4"><h1>

Login</h1></td>

</tr>

<tr>

<td><font face="Times New Roman" color="black" size="3">username:</td><td><input

type="text" name="username" autocomplete="off" required x-moz-errormessage="" title="Enter
your role" value="" size="20%" placeholder="Username"></input></td></tr>

<tr>

<td><font face="Times New Roman" color="black" size="3">Password:</h2></td><td><input

type="password" name="password" autocomplete="off" required x-moz-errormessage="Please
enter the Password" title="Enter the Password" value="" size="20%" id="txt_password"
placeholder="Password"></input></td></tr>

<tr>

<td colspan=2 align=center><input type='submit' class="button_example" value='login'

name='submitMain' Onclick="return check(this.form);"/></td></tr>

<tr>

85
<td colspan=2 align=center><a href="forget.php"><font face="Times New Roman"
color="black" size="3">Forget Password</a></td></tr></table>

</form>

<!--Php Script-->

<?php

if (isset($_POST['submitMain']))

$username=$_POST['username'];

$password=$_POST['password'];

$sql ="SELECT * FROM user WHERE username='$username' AND

password='$password'";

$result = mysql_query($sql);

// TO check that at least one row was returned

$rowCheck = mysql_num_rows($result);

$row=mysql_fetch_array($result);

if($row['role']=='hrm'){

$_SESSION['SESS_MEMBER_ID']=$confirmation;

echo "<script>window.location='Hrm.php';</script>";

else if($row['role']=='collegedean'){

$_SESSION['SESS_MEMBER_ID']=$confirmation;

echo "<script>window.location='collagehome.php';</script>";

else if($row['role']=='Departmenthead'){

$_SESSION['SESS_MEMBER_ID']=$confirmation;

86
 echo "<script>window.location='viewdepartment.php';</script>";

else if($row['role']=='user'){

$_SESSION['SESS_MEMBER_ID']=$confirmation;

echo "<script>window.location='viewnotifivationuser.php';</script>";

else if($row['role']=='dept'){

$_SESSION['SESS_MEMBER_ID']=$confirmation;

echo "<script>window.location='departmanthead.php';</script>";

else if($row['role']=='Admin'){

$_SESSION['SESS_MEMBER_ID']=$confirmation;

echo "<script>window.location='admin.php';</script>";

else if($row['role']=='finance'){

$_SESSION['SESS_MEMBER_ID']=$confirmation;

echo "<script>window.location='finance.php';</script>";

else if($row['role']=='biology'){

$_SESSION['SESS_MEMBER_ID']=$confirmation;

echo "<script>window.location='Biology.php';</script>";

else if($row['role']=='cs'){

$_SESSION['SESS_MEMBER_ID']=$confirmation;

87
 echo "<script>window.location='CS.php';</script>";

else if($row['role']=='is'){

$_SESSION['SESS_MEMBER_ID']=$confirmation;

echo "<script>window.location='IS.php';</script>";

else if($row['role']=='it'){

$_SESSION['SESS_MEMBER_ID']=$confirmation

echo "<script>window.location='IT.php';</script>";

else

echo'<br>';

echo' <p class="wrong">Check Your username or Password!</p>';

echo' <meta content="5;index.php" http-equiv="refresh" />';

mysql_close($conn);

?>

</td>

</tr>

</table>

</td>Sample code for view complaint

<?php

session_start();

include ("connection.php");

88
if(isset($_session['counter']))

$_session['counter']+=1;

else

$_session['counter']=1;

?>

<?php

if(isset($_SESSION['username'])&&isset($_SESSION['password'])&&isset($_SESSION['role'])
)

$username=$_SESSION['username'];

$password=$_SESSION['password'];

$role=$_SESSION['role'];

}else

?>

<?php

?>

<?php

include('connection.php');

?>

<script type = "text/javascript" >

function preventBack()

window.history.forward();

89
}

setTimeout("preventBack()", 0);

window.onunload=function(){null};

</script>

<script type= "text/javascript">

function dat(){

var date=new Date();

var x=date.getDate();

var y=(date.getMonth()+1);

var z=date.getFullYear();

dd=document.user.date.value=z+"/"+y+"/"+x;

</script

<head>

<link rel="stylesheet" href="css.css">

</head>

<head>

</head>

<body bgcolor="#a8e6d7" >

<div id="main">

<?php //include('Reg System/login1.php'); ?>

<div id="header" style="border-color:#f7e360;background-color: #b9f2fd;height: 115px;margin-

top: -3px; width: 100%;margin-left: -2px;"

<img src="image/titl.png" align="left" width="99%" height="110px" border="5px red">

</div>

90
<div id="menu" >

<ul class="navbar" style="text-transform: capitalize" >

<li> <a href="deptview.php" ><h4 style="margin-left: 50px">home</h4></a></li>

<li> <a href="studreg.php" ><h4 style="margin-left: 50px">complian register</h4></a></li>

<li><a href="#" target=""><h4>View</h4></a>

<ul>

<li><a href="viewnotifivationuser.php" target="">Notification</a></li>

</ul></li>

<li><a href="cchatchat.php" target=""> chat</a></li>

<li> <a href="viewrequest.php" ><h4 style="margin-left: 50px">viewrequest</h4></a></li>

<li> <a href="logout.php" ><h4 style="margin-left: 50px">Logout</h4></a></li>

</ul>

</div>

<?php

include('liuser.php');

?>

<div id="display">

<div id="content">

<p style="line-height: 2;font-family: times new roman">

<form action="" method="POST" name="user" onsubmit="return valdation();">

<table>

<tr>

<td colspan="3"
align="center">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;

<input type="button"value="Date"onclick="dat();"/>&nbsp;&nbsp;&nbsp;

91
<input type="box" name="date"readonly="" placeholder="click date button to fill"/></td>

</tr>

<tr>

<td style="color:black;" required pattern="">

status:<td>

<select name="stutus">

<option>--select status--</option>

<option>student</option>

<option>lecturer</option>

<option>staff</option>

</select>

</td>

</tr>

<tr><td>Reciver(role) </td> <td>

<select name="role" required="required" >

<option>--Selec reciver--</option>

<option value='handling'>IT</option>

<option value='college dean'>IS</option>

<option value='handling'>CS</option>

<option value='college dean'>Accounting</option>

<option value='handling'>Biology</option>

<option value='college dean'>E.enginnering</option>

<option value='college dean'>HO</option>

</select></td></tr>

<tr>

92
<td style="color:black;">

<form action="" method="post">

<b> select department name </b>

<?php

require("connection.php");

echo "<select name=organ required=required>

<option value=''>--select--</option>";

$query = "SELECT * FROM dept ORDER BY dept_name";

$result = mysql_query($query) or die(mysql_error());

while ($row = mysql_fetch_array($result))

echo
"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<option value='IT'>

".$row['dept_name']."</option>";

echo "</select>";

?>

<br />

</td>

</tr>

<tr>

<td style="color:black;">

cause:<td><input type="text" name="cause" class='name' style="text-transform: capitalize;

93
" placeholder='Write your address here' required pattern="[a-zA-Z ]+" title="fill the
field"/></td>

</tr>

<tr>

<td style="color:black;">

Discription:</td><td><textarea name="description"style="height: 200px;width: 250px;"

required="" >

</textarea></td>

</tr>

<tr>

<td align="left"> <b> evidence </b> </td>

<td><input type="file" name="evidence" > </td>

</tr>

<tr> <td></td>

<td>

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<input
type="submit"name="submit"value="Register"/>

&nbsp;&nbsp;<input type="reset"name="reset"value="Reset"/>

</td>

</tr>

</table>

<?php

if(isset($_session['role'])){

$conn=mysql_connect("localhost","root","") or die(mysql_error());

$sdb=mysql_select_db("complian",$conn) or die(mysql_error());

$select=mysql_query("select * from employee WHERE emp_id='$_SESSION[role]'");

94
while($row1=mysql_fetch_array($select)){

$s=$row1['sex'];

$a= $row1['age'];

$na=$row1['name'];

$fna= $row1['fname'];

$add= $row1['address'];}

?>

<?php }?>

</form>

</div>

<div >

</div>

</div>

<?php

//include('right/footer.php');

?>

<?php

//include('right/right.php');

?>

</div>

</body></html>

<?php

if(isset($_POST['submit']))

$con=mysql_connect("localhost","root","");

95
mysql_select_db("complian",$con);

$date=$_POST['date'];

$stutus=$_POST['stutus'];

$reciver=$_POST['role'];

$organ=$_POST['organ'];

$cause=$_POST['cause'];

$description=$_POST['description'];

$evidence=$_POST['evidence'];

$role=0;

$query1=mysql_query("select * from user WHERE role='$role'");

while($query2=mysql_fetch_array($query1))

$username=$query2['username'];

$sql="INSERT INTO
register(IDno,name,fname,sex,age,address,date,stutus,role,organ,cause,description,evidence,statu
s)

values('$_SESSION[username]','$na','$fna','$s','$a','$add','$date','$stutus','$reciver','$organ','$cau
se','$description',

'$evidence','unread')";

$query=mysql_query($sql);

if($query==1)

echo '<script type="text/javascript">

alert("your request is send successful!")</script>';

96
else{

echo"<br/><br/>Not successfull". mysql_error();

if(isset($_FILES['image'])){

$errors= array();

$file_name = $_FILES['image']['name'];

$file_size =$_FILES['image']['size'];

$file_tmp =$_FILES['image']['tmp_name'];

$file_type=$_FILES['image']['type'];

$file_ext=strtolower(end(explode('.',$_FILES['image']['name'])));

$expensions= array("jpeg","jpg","png");

if(in_array($file_ext,$expensions)=== false){

$errors[]="extension not allowed, please choose a JPEG or PNG file.";

if($file_size > 20971){

$errors[]='File size must be excately 200kb';

if(empty($errors)==true){

move_uploaded_file($file_tmp,"uploads/".$file_name);

echo "Success";

}else{

print_r($errors);

}}}

?>

Sample code to integrate android with php

97
import java.io.BufferedReader;

import java.io.IOException;

import java.io.InputStream;

import java.io.InputStreamReader;

import java.io.UnsupportedEncodingException;

import java.util.List;

import org.apache.http.HttpEntity;

import org.apache.http.HttpResponse;

import org.apache.http.NameValuePair;

import org.apache.http.client.ClientProtocolException;

import org.apache.http.client.entity.UrlEncodedFormEntity;

import org.apache.http.client.methods.HttpGet;

import org.apache.http.client.methods.HttpPost;

import org.apache.http.client.utils.URLEncodedUtils;

import org.apache.http.impl.client.DefaultHttpClient;

import org.json.JSONException;

import org.json.JSONObject;

import android.util.Log;

public class JSONParser {

static InputStream is = null;

static JSONObject jObj = null;

98
static String json = "";

// constructor

public JSONParser() {

// function get json from url

// by making HTTP POST or GET mehtod

public JSONObject makeHttpRequest(String url, String method,

List<NameValuePair> params) {

// Making HTTP request

try {

// check for request method

if(method == "POST"){

// request method is POST

// defaultHttpClient

DefaultHttpClient httpClient = new DefaultHttpClient();

HttpPost httpPost = new HttpPost(url);

httpPost.setEntity(new UrlEncodedFormEntity(params));

HttpResponse httpResponse = httpClient.execute(httpPost);

HttpEntity httpEntity = httpResponse.getEntity();

99
 is = httpEntity.getContent();

}else if(method == "GET"){

// request method is GET

DefaultHttpClient httpClient = new DefaultHttpClient();

String paramString = URLEncodedUtils.format(params, "utf-

8");

url += "?" + paramString;

HttpGet httpGet = new HttpGet(url);

HttpResponse httpResponse = httpClient.execute(httpGet);

HttpEntity httpEntity = httpResponse.getEntity();

is = httpEntity.getContent();

} catch (UnsupportedEncodingException e) {

e.printStackTrace();

} catch (ClientProtocolException e) {

e.printStackTrace();

} catch (IOException e) {

e.printStackTrace();

try {

100
 BufferedReader reader = new BufferedReader(new
InputStreamReader(

is, "iso-8859-1"), 8);

StringBuilder sb = new StringBuilder();

String line = null;

while ((line = reader.readLine()) != null) {

sb.append(line + "\n");

is.close();

json = sb.toString();

} catch (Exception e) {

Log.e("Buffer Error", "Error converting result " + e.toString());

// try parse the string to a JSON object

try {

jObj = new JSONObject(json);

} catch (JSONException e) {

Log.e("JSON Parser", "Error parsing data " + e.toString());

// return JSON String

return jObj;

101
 }

6.3 Hardware Software Acquisition

To do this project we use different hardware and software parts like that of:

Hardware

 Desktop computer for doing all activity ,implementing the software

 Printer for printing all document part
 Flash to transfer data from one computer to other.

Software

 Edraw max, visaw and enterprise archtechture for the drawing of some diagrams like use
case diagram
 PHP (xampp) server and MYSQL to develop our data base system.
 Microsoft word for any requirements like that of writing our documentation.

6.4 User Manual Preparation

We have been prepared a user manual link as a help in the first homepage design that can guide
users when they get any confusion during their usage. These are:

In order to login the system users must have:

1. Register first

2. User-name, password and role to login the system

Authentication and authorization principle

If you have any user:

See any information available in the system without log on the system

1. Register complain

2. View notification

3. Write a feedback to employees

3. View images or gallery of about the system

4. Use contact as link to contact with the organization

102
6.5 Training
Before giving any training on our project to the owner and manager the university, this system
deployed and then we can give the training without any difficulty and too many who wants to
have the knowledge of this web application if it is necessary. During the deployment of this
system, the project group members will give short time training for the system administrators
explaining how the system works and in what way they can manage the system

6.6 Installation Process

A computer or smartphone requires to run the web based program. In addition xampp software
needs to be installed and configured so that the database and other web based interrelated
functions can be processed.

6.7 Start-up Strategy

In the first step of using the system users can access all information about the university and
also can send complaints to the offices but to get decision response users must be registered as a
member. After he/she would be the member of the system, then the next step is login to enter
into the page.

103
 7 Chapter Seven

CONCLUSIONS AND RECOMMENDATIONS

7.1 Conclusions
This project aimed to develop system that minimizes in compliant in Debre berhan University. In
first chapter; we determined the title of the project that is compliant management system. we
described the background of the organization with the explanation of how the organization is
established, the problems of the existing system faced during accomplishing their tasks, the
objective of this project, the scope and limitation of the project, significance of the project,
feasibility and breakdown of the structure have been discussed including the methodology of the
project which describes what and which material the team used to accomplished the project.

In second chapter we identified detailed business area analysis, definition what the current
system looks like. In business area analysis we identified activities of the current system, the
problems of the current system, the forms and reports currently used. Secondly business rule
identification and use case diagram with essential use case modeling to model features of the
existing system by identifying actors and use cases. Thirdly we determined the requirements of
the proposed system in terms of functional and non functional requirements. Finally, we identify
user interface prototyping that describes the user interface requirements in a technology
independent manner. In second chapter, we discussed about the object oriented analysis with
detail explanation. To accomplish this, we used different types of object oriented analysis tools
like: system use case, different diagram such as, sequence diagram, class diagram and activity
diagram including user interface prototyping which is an extension of the essential user
interface. Here the actual new system of the project are studied theoretically with every steps of
the system in the manner other people can understand our project.

The computers and computerization technology in the world is growing along the fast lane where
Ethiopia is attempting to run along this lane in which there are achievements recorded. And as
years, pass by, we are pretty much confident that extent progress will be made in our country.
System development is one of the ways in which we can make progress by making a lot of tasks
easier and the overall use of computers along with the developed systems is believed to lead to
the peak of the technology standard. It is known that developing a system for an organization is

104
not easy. But the team tried its best to develop best complaint mobile application and web based
system for Debre Berhan University.

Generally, the team confidently can say that the software is completed successfully with
negligible errors.

The system is strongly secure with the use of identification user name and a password.

The android part uses two languages which are our local language Amharic and English.

The developed system can conclusively be called user friendly in which the form developed are
suitable for use by any user who will defiantly get accustomed to the system’s environment
easily.

7.2 Recommendations
 We recommend that if the system support not to accept bad words.
 If the decision will be sent by users email
 Training user should be considering for best performance and efficiency of It technology.
 If the next developer in includes all branches of offices, departments and other organs we will not
consider

105
7.3 APPENDIX
Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency.

Actors: Actors are the type of users that interact with the system.

Class diagram: is a type of static structure diagram that describes the structure of a system by
showing the system's classes their attributes, operations (or methods), and the relationships
among objects.

Conceptual model is a model made of the composition of concepts which are used to help
people know, understand or simulate a subject the model represents.

Sequence diagram is an interaction diagram that shows how processes operate with one another
and what is their order.

Use case: is a methodology used in system analysis to identify, clarify, and organize system
requirements.

Use case diagram: is a graphic depiction of the interactions among the elements of a system.

User interface prototyping: is an iterative development technique in which users are actively
involved in the mocking-up of the UI for a system.

106
7.4 References
[1] Abdi Mulatu, “E-complaint management system and GIS mapping for Addis Ababa
city administration”, Addis Ababa University, Ethiopia, June 2011.

[2] Ministry of Communication and Information Technology, “Ethiopian Electronic Services”,

2012, retrieved from http://www.eservices.gov.et/eServicePortalEth/, (last accessed on March

02, 2014)

[3] Government of Ethiopia, “Ministry of Communication and Information Technology”, 2012,

retrieved fromhttp://www.mcit.gov.et/web/english/ict-sector-development-in-ethiopia, (last

accessed on March 06, 2014)

[4] Gustaf Juell-Skielse, “Enhancing Complaint and problem Management: design and

evaluation of an M-service using pictures and positioning”, Royal Institute of

Technology, Sweden, 2010.

[5] Amir Shareghi Najar, “The Application of Service Oriented Architecture in E-

complaint system”, University of Malaya, Malaysia, 2009.

[6] AjinkyaAmrute, “cloud based complaint management service”, San Jose state
university California, USA, April 2013.

[7] Ethiopia Investor, “Mobile Governance Service to Start in September”, retrieved from

http://www.ethiopiainvestor.com/index.php?view=

&catid=1:latestnews&id=4326:mobilegovernance-service-to-start-in-
september&option=com_content (last accessed on February 27,

2014)

107
108