KWSSO water44

Wollo University

KIOT

College of Informatics

Web Based Customer Service Management System for Kombolcha Water

Supply Service Office (CSMS for KWSSO)

A Project paper submitted to the Department Of Computer science of Wollo University in partial fulfillment of the requirements for the

Degree of Bachelor of Science in Computer Science

BY:

1. Mesfin Shifera

2. Kalkidan Misganaw

3. Aliheyder Jemal

4. Adamu Girma

5. Tigst Yimam

6. Teshome W/tensey

Advisor: Mr. Yonas Abate

June, 2014

Kombolcha

CUSTOMER SERVICE MANAGEMENT SYSTEM FOR KOMBOLCHA WATER SUPPLY SERVICE OFFICE(CSMS for KWSSO)

2006 E.C

Acknowledgments

We would like to thank GOD for giving us strength and health to complete this project. We also

grateful to our advisor Mr. Yonas Abate for his motivate and constructive guidance as of the

beginning of problem formulation to the completion of the project.

We would like to forward our special thanks to Kombolcha city water supply service office staff

employee.

Finally, we want to extend our thanks to our parents for their encouragement, Motivation and

support throughout our study.

CSMS FOR KWSSO Page i


2006 E.C

AbstractThe Web Based Customer Service Management System for kombolcha water supply service

office (KWSSO) is a web-based system service designed to facilitate the burden of different

activities such as registration of new customer, bill processing, post vacancy announcement,

material registration, and customer maintenance order request and record meter reading and the

like. Essentially the system consists of four large components or departments. The first

component is bill officer. This component is having different activities such as bill processing,

record meter reading. The second component (department) technical supervisor staff. It having

different activities such as receives maintenance order, reject maintenance order, store

maintenance, delete and update maintenance and the like. The third department is Customer

service expert this also having different activities such as update customer record, delete

customer record and view customer payment for giving customer service. The fourth component

is Manager this staff can view different department activities.

In general, Web Based Customer Service Management System for kombolcha water supply

service office (KWSSO) has its own desktop application system for calculating bill; but the

desktop application system can give service only employee that means the system displays only

employee customer no contribute to the system. When customer apply register for service

request must be physically exist to the office, can’t give comment (feedback) to the organization

and difficult to maintenance order requests and difficult to vacancy announcement and the likes.

So, the group initiated to solve the problem by their final year project. Therefore, we wish the

department will provide all the necessary things to accomplish the project.

This document deals with the system analysis and design of Web Based Customer Service

Management System for kombolcha water supply service office (KWSSO). This is mostly used

for the system users that we have described in the different parts of this document. Computerized

is the basic ways for the office in every of its activity it must be changed into computerized

system software in order to reduce the delay of work. This document has tangible and intangible

benefits for the office and it also describes how tasks performers in the existing system.

CSMS FOR KWSSO Page ii


2006 E.C

Table of Contents

Acknowledgments........................................................................................................................................ i

Abstract....................................................................................................................................................... ii

Lists of table...............................................................................................................................................vi

Lists of Figures..........................................................................................................................................vii

Abbreviation and Acronyms........................................................................................................................x

CHAPTER ONE: INTRODUCTION..........................................................................................................1

1.1 Background.....................................................................................................................................2

1.1.1 Vision.........................................................................................................................................2

1.1.2 Mission.....................................................................................................................................2

1.2 Description of the existing system.....................................................................................................3

1.3 Statement of the problem and justification of execution the project..................................................3

1.3.1 Statement of the Problem............................................................................................................3

1.3.2 Justification for execution of the project.....................................................................................4

1.4 Objective of the project...................................................................................................................4

1.4.1 General objectives....................................................................................................................4

1.4.2 Specific objectives......................................................................................................................4

1.5 Scope and limitation of the project....................................................................................................4

1.5.1 Scope of the project................................................................................................................4

1.5.2 Limitation of the project.............................................................................................................5

1.6 Risks..................................................................................................................................................5

1.7 Methodology.....................................................................................................................................6

1.7.1 Method of data collection...........................................................................................................6

1.7.2 System analysis and design methodology...................................................................................6

1.8 Hardware and Software Tools of the system development................................................................7

1.8.1 Hardware tools required are:.......................................................................................................7

1.8.2 Software tools required are:........................................................................................................7

1.9 Cost of the project..............................................................................................................................8

1.10 Schedule of the project....................................................................................................................9

1.11 Task Breakdown and Deliverables..................................................................................................9

1.12 Communication plan......................................................................................................................10

CSMS FOR KWSSO Page iii


2006 E.C

1.13 Feasibility of the project................................................................................................................10

1.13.1 Technical feasibility................................................................................................................10

1.13.2 Schedule Feasibility................................................................................................................11

1.13.3 Operational Feasibility............................................................................................................11

1.13.4 Legal Feasibility.....................................................................................................................11

1.13.5 Economic Feasibility..............................................................................................................11

1.14 Benefits and beneficiaries of the project........................................................................................11

1.14.1 Benefits of the project.............................................................................................................11

1.14.2 Beneficiaries of the project.....................................................................................................12

CHAPTER TWO: BUSINESS AREA ANALYSIS..................................................................................13

2.1 Description of current/ existing system............................................................................................13

2.2 Problem identified and alternative solution.....................................................................................13

2.2.1 Problem of the existing system.................................................................................................13

2.2.2 Alternative solution..................................................................................................................14

2.3 Option analysis and the proposed new system.................................................................................14

2.4 Overview of the proposed system....................................................................................................15

2.5 Requirement definition....................................................................................................................16

2.6 Essential use case modeling.............................................................................................................17

2.6.1 Essential use case description...................................................................................................18

2.7 System Requirement........................................................................................................................22

2.7.1 Functional requirements...........................................................................................................22

2.7.2 Non-Functional requirements...................................................................................................23

CHAPTER THREE: OBJECT ORIENTED SYSTEM ANALYSIS.........................................................25

3.1 Introduction.....................................................................................................................................25

3.2 Objective of system analysis............................................................................................................25

3.3 System Requirement Specifications (SRS)......................................................................................25

3.3.1 Use case diagram......................................................................................................................25

3.4 Use case documentation..................................................................................................................27

3.5 Sequence diagram............................................................................................................................36

3.6 Activity diagram..............................................................................................................................47

3.7 User interface prototype..................................................................................................................59

CSMS FOR KWSSO Page iv


2006 E.C

CHAPTER FOUR: SYSTEM DESIGN....................................................................................................60

4.1 Introduction.....................................................................................................................................60

4.2 Class Type Architecture..................................................................................................................60

4.3 Class modeling................................................................................................................................62

4.4 State chart modeling........................................................................................................................63

4.5 Component Modeling......................................................................................................................71

4.6 Deployment modeling.....................................................................................................................72

4.7 User Interface design.......................................................................................................................73

CHAPTER FIVE: IMPLIMENTATION...................................................................................................80

5.1 System Implementation...................................................................................................................80

5.2 Coding..............................................................................................................................................87

5.3 Testing.............................................................................................................................................93

5.3.1 Unit Testing..............................................................................................................................93

5.3.2 System Testing.........................................................................................................................95

5.4 User manual preparation..................................................................................................................95

CHAPTER SIX: CONCLUSIONS AND RECOMMENDATION...........................................................96

6.1 Conclusions.....................................................................................................................................96

6.2 Recommendation.............................................................................................................................97

References.................................................................................................................................................98

CSMS FOR KWSSO Page v


2006 E.C

Lists of table

1 Page

Table 1.1 project cost plan ………..…………………………………………………………….9

Table 1.2 Project schedule………………………………………………………………….…...9

Table 1.3 Task Breakdown and Deliverables …........................................................................10

2

Table 2.1 Apply register for service for service ………..………….………………………….18

Table 2.2 Update customer record ………..………………………………….…….…………19

Table 2.3 Delete customer record.....................................................................…......................19

Table 2.4 Post vacancy………..…………………………………………….…………………20

Table 2.5 Create account………..…………………………………………….…………………20

Table 2.6 record meter reading………..……………………………………….………………21

Table 2.7 record maintenance material………..……………..………………….……………..21

Table 2.8 view report…………………………………………………………………….…....22

3

Table 3.1 Use case documentation for Login………………………………………………….28

Table 3.2 Use case documentation for Create Account…………………..……………………29

Table 3.3 Use case documentation for Delete Account…………………….………………….30

Table 3.4 Use case documentation for Apply register for service………….………….……….30

Table 3.5 Use case documentation for Update customer record………………………….….....31

Table 3.6 Use case documentation for Delete customer record…...............................................32

Table 3.7 Use case documentation for Order maintenance………………………….…….…..32

Table 3.8 Use case documentation for Receive maintenance……………………….…….…...33

Table 3.9 Use case documentation for View report …………………………………………..33

Table 3.10 Use case documentation for Process payment bill…………………….…….…….34

Table 3.11 Use case documentation for Record meter reading………………….…….……....35

Table 3.12: Use case documentation for Post vacancy .......................................................…...35

CSMS FOR KWSSO Page vi


2006 E.C

Table 3.13: Use case documentation for Delete post vacancy…………………….………..36

Table 3.14: Use case documentation for record maintain material…………………………36

Table 5.1: Test Case1: for Create Account………………………………………………....94

Lists of Figures

2 Page

Fig 2.1: Essential use case diagram ………………………………………………….………..17

Fig 3.1: UML use case diagram …………………………………………………....………….27

3

Fig 3.2: UML Sequence diagram for Customer Apply Register for service…………….…….37

Fig 3.3: UML Sequence diagram for View report …………………………………….………38

Fig 3.4: UML Sequence diagram for Update Customer record………………………….….....39

Fig 3.5: UML Sequence diagram for Order Maintenance ………………………….….….......40

Fig 3.6: UML Sequence diagram for Delete Customer record………………………….……..41

Fig 3.7: UML Sequence diagram for Receive maintenance ………………………….…........ 42

Fig 3.8: UML Sequence diagram for Create account ………………………….………….......43

Fig 3.9: UML Sequence diagram for Delete account ………………………………………...44

Fig 3.10: UML Sequence diagram for login ………………………….………...……….….…45

Fig 3.5.11: UML Sequence diagram for water meter reading…………………………….…..46

Fig 3.12: UML activity diagram for Apply Register for service………………………….…...47

Fig 3.13: UML activity diagram for Login administrative staffs……………….….….….…...48

Fig 3.14: UML activity diagram for View report………………………………….…………..49

Fig 3.15: UML activity diagram for record meter reading………………………….….……...50

Fig 3.16: UML activity diagram for Process payment bill ………………………….…….…..51

Fig 3.17: UML activity diagram for Receive maintenance…….…………………….……......52

Fig 3.18: UML activity diagram for Order maintenance……………………………………...53

Fig 3.19: UML activity diagram for Create account ……………………………………........54

Fig 3.20: UML activity diagram for Delete account………………………………….. ……....55

Fig 3.21: UML activity diagram for Delete customer record….................................................56

CSMS FOR KWSSO Page vii


2006 E.C

Fig 3.22: UML activity diagram for Update Customer record ………………………………..57

Fig 3.23: UML activity diagram for post vacancy….................................................................58

Fig 3.24: User interface prototype….........................................................................................59

4

Figure 4.1: Class type architecture….………………….. ……………………….………….....61

Figure 4.2: Class Diagram….…………………………………………………….…………….62

Fig 4.3: State chart diagram for login…………………………………………….…………….63

Fig 4.4: State chart diagram for update payment………………………………….…………...64

Fig 4.5: State chart diagram for record meter………………………………………..…………65

Fig 4.6: State chart diagram for Material register…………………………………..……….….66

Fig 4.7: State chart diagram for Customer register………………………………….………….67

Fig 4.8: State chart diagram for view report…………………………………….……………...68

Fig 4.9: State chart diagram for post vacancy………………………………….…….…………69

Fig 4.10: State chart diagram for create account…………………………….…….….….….….70

Fig 4.11: Component modeling………………………………………………………………....71

Fig 4.12: Deployment modeling………………………………………………………………...72

Fig 4.13: Home page….................................................................................................................73

Fig :4.14 login form UI……………………………………………………….…..…....….……74

Fig :4.15 Create accounte form UI…………………………………………………………......74

Fig :4.16 Customer Register form UI………………………………………….……......….…..75

Fig :4.17 Update Delete Account form UI……………………………………….…..….....…..75

Fig :4.18 Search Customer record UI………………………………………………………….76

Fig :4.19 Delete Update Customer record form UI……………………….……………..……76

Fig :4.20 Register maintain material form UI………………………………….…….……….76

CSMS FOR KWSSO Page viii


2006 E.C

Fig :4.21 Delete update maintain material…………………………….…….…….….………..77

Fig :4.22 Search maintain material………………………………………….……..….……….77

Fig :4.23 Search payment UI……………………………………………….….………..……..77

Fig :4.24 Payment register form UI………………………………………….….….…………78

Fig :4.25 Delete update vaccancy……………………………………………..….….………...79

Fig :4.26 Post vaccancy form UI……………………………………………….…...…………79

Fig :5.1 Home page……………………………………………….………………..….………80

Fig :5.2 Customer page………………………………………………………….……..………81

Fig :5.3 Order request form………….………………………………………….…….…….…82

Fig :5.4 Bill generate form…………………………………………………………….………82

Fig :5.5 Administrator page …………………………….……………………….……………83

Fig :5.6 Admin login……………………………………………………………….….………83

Fig :5.7 Bill officer page………………….………………………………………....………...84

Fig :5.8 Technical supervisor page………………….…………………………..….…………85

Fig :5.9 Technical supervisor Login…………………………………………………..………85

Fig :5.10 Customer service expert page………………….………………………........……...86

Fig :5.11 Manager page………………………….………………………..……………......…87

CSMS FOR KWSSO Page ix


2006 E.C

Abbreviation and Acronyms

KWSSO: Kombolcha water supply service office

CSE: Customer service expert

TSV: Technical supervisor

UML: Unified modeling language

OOA: Object oriented analysis

OOD: Object oriented design

PHP: Hypertext Preprocessor

HTTP: Hyper Text Transfer Protocol CSMS: Customer Service management system SRS: System requirement specification

HTML: Hypertext markup language

CSS: Cascading Style Sheet OS: Operating system UI: User interface

CSMS FOR KWSSO Page x


2006 E.C

CHAPTER ONE: INTRODUCTION

As we know, today our world is under the control of technology because of this reason the world

are related each other. Our country is one part of the world but, we are too late according to this

technology as compare as others western countries.

Even if our country is not developed in this project, we try to change the desktop application

system of kombolcha water supply service office (KWSSO) into web based system using today’s

technology. KWSSO has many activities. Such as, Customer registration, Calculating bill based

on their customer information and the likes. When we see how the new customer joins the

organization, it requires physical present to the office. So, the project try to reduce this problem

and enable the office system to have very fast service to their customer by designing web based

service management system for them.

CSMS FOR KWSSO Page 1


2006 E.C

1.1 Background

Kombolcha water supply service office (KWSSO) is a water supply Organization which found in

Kombolcha city. The organization establishes in 1962E.C.At that time the offices have only 5

employees (one water clearance expert (water chemist), one motor operator, one meter reading

expert and two Security bodies).Until 2003E.C KWSSO follows manual based office system

which means, they follow traditional way of giving service for their customer. At 2003E.C the

office develop its own Desktop application system. This Desktop application limited to customer

register and calculate belling system. Not generate organized report; the information can’t visible

to customer, and the likes. The system only visible to employee. Until 1971E.C the office has

only 300 customers which register to use the service.

Currently the office have 80 employees(29 technician staff,51 management and finance staff)

from those 20 women and 60 mens.This office done many activities like, customer registration,

Bill process calculating, and meter number registration and viewing reports for them, taking

customers maintenance order and respond it. Currently, this organization has 10128 customers

and has 80 employees which they register under this office. [10]

1.1.1 Vision

The vision of KWSSO is to see produced enough and pure water for drinking, for industrial, and

for irrigation of city, for the population living in Kombolcha city and it’s around. [10]

1.1.2 Mission

The mission of KWSSO is to increase income with direct proportional of balancing city’s

development and by adding extra water resource areas to give pure and enough water for the

city’s societies. [10]



2006 E.C

1.2 Description of the existing system

Kombolcha water supply service office (KWSSO) is using Desktop application system.

Registration of new customers and bill calculating using by this system. But, the system can’t

work organized activity, detail customer information can’t visible to customer, when we see how

the new customer joins the organization, it requires physical present to the office. The

organization vacancy announcement submits by paper or on the board.

Existing system is difficult for:-

Vacancy announcement,

Getting feedbacks from the customer,

Making comments to customers,

Searching single data is time consuming,

Deleting Updating customer data is difficult,

Customer view its own payment is difficult etc.

Kombolcha water supply service office (KWSSO) Desktop application system is time taking,

unqualified, costly and not satisfactory. Employee 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, it must physically join to the office, customers cannot see their payment on time.

1.3 Statement of the problem and justification of execution the

project

1.3.1 Statement of the Problem

KWSSO is currently uses Desktop application systems. As it is desktop application, they have

their own problem like:

Vacancy announcement,

Registration of material,

Registration of meter reading,

Getting feedbacks from the customer,



2006 E.C

Searching for even single data is time consuming,

Redundancy (multiple records of the same data),

The organization information can’t visible to customer etc.

1.3.2 Justification for execution of the project

We are interested to overcome and solve the above mentioned problems by developing web

based system. We believed that the new proposed system will help the kombolcha water supply

service office (KWSSO) to accomplish their tasks such as customers’ registration, storing and

retrieving customers’ information as well as order request from the customer in efficient and

effective manner. Post vacancy announcement, getting feedbacks from the customers.

1.4.2 Specific objectives

Studying the background of the organization,

Develop a database that holds information about customer,

Identifying the problem under the existing system,

System analysis and object design,

Implementations of the system,

Testing of the system,

Requirement analysis of the system,

Documenting the whole system.

1.4 Objective of the project

1.4.1 General objectives

The general objective of the project is to develop web-based customer service management

system for Kombolcha water supply service office (KWSSO).

1.5 Scope and limitation of the project

1.5.1 Scope of the project

Web based system of KWSSO is too huge in its scope but, the project is limited on the following

points only:-



2006 E.C

On the registration of the new customers.

Give Vacancy announcement for customer and employee.

On the registration of the maintain material.

On the registration of meter reading.

On the registration of the payment.

Customer Bill generates.

Updating, deleting, searching customers by the employee of the office which are

responsible for the appropriate task.

1.5.2 Limitation of the project

The project does not work about employee management because of the following limitation.

Some limitations of our project are:

Lack of Materials: There is no enough computer access, books and references used to show

how Project will be done.

Shortage of time: We are student and in learning process we have shortage of time to complete

the project in one semester. This enforces our project team to minimize the project scope.

Shortage of money: As we are students it is difficult to spend much amount of money on the

project so it limits the effectiveness of the project.

1.6 Risks

During the development of the project there may be different problems that we may face. These

are:

Unfortunate failure of system: To handle this problem the teams have some method to

resist not completely but partially by using back up mechanisms using flash disks,

CD/DVD and by storing the data in more than two computers.

Power problem: we tried to use laptops to cover the gap happened to our project during

power failure.

Virus attack: It is difficult to control data from virus but try to scan the data, installing

and updating antivirus software.



2006 E.C

Time management problem: we solve this problem by working cooperatively, divide our

time by schedule for each phase of the project and we try to use this schedule effectively

One of our group members may be sick while in the process of project development: to

solve this problem the remaining group member together covers this member done.

Therefore whatever situation happen or occurred that hinder during the

progression of the project the team try the best to do what expected and

reform it.

1.7 Methodology

1.7.1 Method of data collection

As we know there are different methods to collect information. From those the project uses the

following tools and methods respectively to collect data from the organization.

Observation (Documentation & material): use this method to get the right

information about the organization and also understand how the existing system

works.

Interview: the team will interview some employee of the organization as well as

the customer to get & share enough and reliable data which is important to do the

project.

1.7.2 System analysis and design methodology

The team plan to use the object oriented design methodology for the development of the system

among the different methodologies. Because it is better way to construct, manage and assemble

objects that are implemented in our system. Object oriented design methodology has two

phases:-

Object Oriented Analysis (OOA): During this phase the team will look at the

problem domain and with the aim of producing a conceptual model of the information that

exists in the area which will be analyzed. And this model the functions of the system (use

case modeling), identifying the business objects, organize the objects and also the

relationship between them and finally model the behavior of the objects.



2006 E.C

Object Oriented Design (OOD): During this phase the model interactions and

behaviors that support the use case scenario, and finally update object model to reflect the

implementation environment. And also transforms the conceptual model produced in

object-oriented analysis to take account of the constraints imposed to our system format, so

that we will use this phase to refine the use case model to reflect the implementation

environment.

1.8 Hardware and Software Tools of the system development

1.8.1 Hardware tools required are:

Personal computer (PC): almost all tasks of our project are performed on

computer.

Flash disk: required for data movement to store & transfer data from one PC to

another PC.

Disks (CD, DVD): necessary for the movement of relevant data and for

backup and recovery mechanism.

Network cable: since our system is web based, it is very necessary

requirement. It is also help us to extract relevant information about our project

from internet.

Server: to store the data.

Stationeries (pen, paper): for writing all necessary documentations

associated with the project.

Note book: to take notes during data collection and for other document.

1.8.2 Software tools required are:

Windows 7 Operating system: will be used for the system since it is readily

available in laboratories.

Browsers: -since our system is web based, it is very necessary requirement.

PHP: -To design the graphical user interface and the whole application.

MYSQL server 2005 :-for designing the database



2006 E.C

Microsoft office Word 2010:-for documenting the corresponding deliverables

associated with the project

Enterprise architecture and Edraw max 6.8: -for designing Unified

Modeling Language (UML) diagrams.

Microsoft Visio: used to draw diagrams.

Adobe Photoshop (CS4): -for editing images.

Macromedia Dreamweaver 8: For writing a code or program of the system.

Wamp Server: - to test the system by running.

1.9 Cost of the project

Even though it is difficult to provide an accurate cost estimates, the following is a rough estimate

of the costs associated with the project.

Types of costs Tool name Quantity Unit price (in

Birr)

Total price (in Birr)

Hardware costs Computer 1 8000 8000

Flash(4 GB) 1 180 180

CD ROM 2 6 12

DVD 2 18 36

Pen 6 3 18

Paper 1 packet 100 100

Note book 1 30 30

Printing and binding 3(copies) 100 300

Software costs Wamp server 1 Free Free

Microsoft office 2007 1 Free Free

Notepad++ 1 Free Free

Microsoft Visio 1 Free Free

Adobe Photoshop 1 Free Free

Windows 7 OS 1 Free Free

Other costs --- --- ---- 300



2006 E.C

Total cost --- --- --- 8,976

Table 1.1: project cost plan

1.10 Schedule of the project

The table below represents the main activities of the project together with their respective start

and end date.

Task name Nov201

3

Dec201

3

Jan2014 Feb2014 Mar2014 Api2014 May2014 Jun2014

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

Requirement

gathering &

preparing

Proposal writing

Document

System analysis

User interface

prototyping

Coding & Testing

Table 1.2: Project schedule

1.11 Task Breakdown and Deliverables

Each part of tasks of the project will be delivered by collaborating with each of the group

members. Each group members has their own responsibility to complete the project successfully.

Number Name Activity

1 Mesfin Shifera In all activity

2 Kalkidan Misganaw In all activity

3 Aliheyder Jemal In all activity

4 Adamu Girma In all activity

5 Tigst Yimam In all activity

6 Teshome W/tensey In all activity



2006 E.C

Table 1.3: Task Breakdown and Deliverables

1.12 Communication plan

We have time frame to meet the project objective. We will meet three times in week to discuss

and reach conclusion about the project work processes. In order to complete the project we have

the common meeting time below:

1.2:00-5:00 AM Saturday

2.2:00-5:00 AM Sunday

3. 9:00 – 12:00 PM Friday.

1.13 Feasibility of the project

Feasibility study is used to investigate the proposed system in multiple dimensions. It used to

indicate whether the system feasible or not. The proposed system can be seen according to the

following literals.

1.13.1 Technical feasibility

It is the process of accessing the developed system by the organization. Technical feasibility is

the measure of practicality of the specific technical solution and the availability of technical

resources and expertise. The proposed system can be easily maintained and repaired without

requiring high Experts or technical assistants, because the system was developed by familiar

programming language (environment).The project team members have learned programming

languages that required for the successful completion of the project such as java script, CSS,

HTML, PHP, MySQL. Team members have the required skill to develop the system, So that the

project can be said technically feasible.

1.13.2 Schedule Feasibility

Schedule feasibility is making sure whether the potential time frames and Completion date can

be met or not .The project team members expected the Project to be completed on time without

any delay.



2006 E.C

1.13.3 Operational Feasibility

This system bring better achievement for the operations performed by the office by providing

efficient registration and storage of customers information, easy updating ,deletion, modification

etc. This increases the efficiency of work in the office. So that one can say that the system is

operationally feasible.

1.13.4 Legal Feasibility

The project team members built the system without violating rules and regulations of the

governments as well as the organization. The system being built is for the sake of productivity of

the organization, so that the project is legally feasible.

1.13.5 Economic Feasibility

Economic feasibility is the process of identifying the financial benefits and costs associated with

the project being developed. Our system will minimize wastage of hard copy materials like paper

and record book.

1.14 Benefits and beneficiaries of the project

1.14.1 Benefits of the project

The main benefits of this system as it is computerized web based system:

It minimizes the customers losing time when they want to access service from the

organization.

The main use of this new proposed system is it introduces the employee of the

organization as well the customers with today’s world technology.

It provides timely information to their employees and also Process Customers request on

time.

It can easily update customer’s record.

It can generate appropriate customer bill automatically.

It increases performance of the organization.

Enhance employee morale of the organization by providing quality service.

Improves the confidence of the system users.



2006 E.C

1.14.2 Beneficiaries of the project

The first beneficiaries of this proposed system is the customers who have knowledge on how to

access information from the internet and those of employee of KWSSO. And the other user of

this system the organization by its own, everybody can join their organization simply and can

understand how they work, and understand what things they done in them. So, within a short

time it becomes more profitable and famous office across the world.

Beneficiaries of the Project:

System users’ beneficiary

Save their time and Reduce work loads

Reduce complexity

Easily access customers’ information from organized database.

Control customers records and reduce data redundancy

Group members Beneficiary:

The project has initiated our team to get knowledge of how to develop the

required system application.

While struggling with some difficulties, the team got a lot of experiences of

solving problems.

CHAPTER TWO: BUSINESS AREA ANALYSIS

In this chapter overview of the existing system, overview of the proposed system functional and

non-functional requirement of the system will be discussed and modeled using unified

modeling language(UML) models.



2006 E.C

2.1 Description of current/ existing system

The main purpose of studying the existing system is to develop a new system which efficiently

performs activities than current one and understanding existing problems. To solve problems

document analysis, form designs, some constraints and rules of the existing system incorporated.

Kombolcha water supply service office (KWSSO) is a water supply office .it is using Desktop

application system. Registration of new customers and bill calculating using by this system. But,

the system can’t work organized activity, detail customer information can’t visible to customer,

when we see how the new customer joins the organization, it requires physical present to the

office. The organization vacancy announcement submits by paper or on the board. The

organization information mostly manually present.

2.2 Problem identified and alternative solution

2.2.1 Problem of the existing system

Most of time uses manual ways to achieve its vision and mission.

Customers and employee are not satisfied.

The customer management is not effective.

It takes more time and effort.

It is very difficult to memorize the exact shelf location and amount of data.

Difficult for vacancy announcement,

Difficult for getting feedbacks from the customer,

Difficult for prepared Customer bill,

2.2.2 Alternative solution

After the team has identified the real problem of the existing system which is in a desktop

application system, the team suggests an alternative option to overcome the problem.

These alternative options are:-

Changing the desktop application system into web based environment.



2006 E.C

Changing the desktop application system into a web based system that works on web

based environment.

Uses computerized and automated way to achieve its vision and mission.

There will be fair service that will tend for satisfaction.

The system is lucky to easily throw exact location and exact amount of data from the

database.

Most of the task will be done by the server side machine so no need of customer and

employee to be contact.

Customers can order request by browsing at their home or office. Because, the proposed

system is web based.

An effective and centered management will be applied.

The system can generate almost all related tasks in short period of time.

Can generate and store information’s to the database.

The team has analyzed all of the alternative options based on the ability of performance,

information flow and service to the users and efficiency. This analysis has enforced to select the

web based system

2.3 Option analysis and the proposed new system

The proposed system is very easy to operate and easily handle all the data and the work done by

the existing systems. Option analysis is means of evaluating the alternative solutions in terms of

their advantages and disadvantages.

Advantage of proposed system:

The new system can be implemented without changing the organization policy.

Loss costly and easy to install.

The new system does not require more human labor.

Processing data with high speed and short hand form.

Data redundancy problem will be avoided with the proposed system.



2006 E.C

Is to reduce human errors by providing user-friendly input and output capabilities

and record keeping.

Performance: The performance of the proposed system does provide fast

response time because it is easy to access data from the stored document.

Efficiency: the web based customer service management system by itself is short

and clear and in this system there is no duplication of data through the new

system is powerful to manage things around web based customer service

management system.

Service: the system can be visited by anybody who is a member of the

organization. The new system gives some activities when a user logged in the

system the system displays vacancy announcement for each users and displays

new posts.

Economy: when we apply web based customer service management system there

will be areas in which cost will be reduced. Example as a result of a new system

the payment too many employees will be reduced. Reduce cost of paper.

Weakness of proposed system:

Requires technical person to handle and manage the system.

The new system needs to have internet connection

2.4 Overview of the proposed system

As previously mentioned in statement of the problem, there are a lot of problems associated with

the current system of the organization. The main aim of the proposed system is to implement

kombolcha town water supply service office web based customer service management system

which allows easily register customer, maintenance order request, follow announcement, and

overcome to those problems.



2006 E.C

2.5 Requirement definition

The project “web based customer service management system for kombolcha water supply service

office “aims at developing website for kombolcha water supply service office (KWSSO) by using

the internet based application.

The system focuses on registering customer’s request, producing customer bill generate,

maintenance order request, views different activity. The main objective of the project is to enable

the organization to facilitate its day to day activity efficiently by using the modern technology. It

minimizes the task load of the organization by allowing them to delegate some part of tasks to the

system.

If this project successfully completed, it will minimize wastage of hard copy materials like paper

and record book. It will illuminate some of the physical activities of the office such customers can

see their payment online without having physical contact with the employee. Customer can

maintenance order request easily by online.



2006 E.C

2.6 Essential use case modeling

Essential use case modeling is a simplified abstract, generalized use case that captures the

intentions of the user in a technology and implementation independent manner. It identifiers use



2006 E.C

case and actors of the proposed system.



2006 E.C

Figure 2.1: Essential use case diagram

2.6.1 Essential use case description

Use case name Apply register for service

Use case number UC1

Description The customer enables to select register link and fills the form and

submit to their record request to view by customer service expert.

Actor Customer

Pre-condition The customer must have internet connection.

Basic course of action

(Flow of event):

Step 1. The customer wants to register by selecting register link.

Step2. The system Displays the register form Page.

Step3.The customer fill the inputs his/her required status.

Step4. The customer click submit button.

Step5.The system displays the ID Number and information’s of the

customer.

Step6. The use case ends.

Post-condition Submit the full fill records to the KWSSO data base

Alternate course of

action:

A: the filled Register information is invalid.

1:Go to step 2 to fill register form again

Table 2.1: Apply register for service

Use case name Update customer record

Use case number UC2

Description The customer service expert enables to select customer update link and

Update or modify the customer data and view the updated data.

Actor Customer service expert(CSE)

Pre-condition The CSE must login to the system by its own user name and password.

Basic course of Step 1. The CSE wants to update by selecting update customer record link.



2006 E.C

action (Flow of

event):

Step2. The system Displays the customer update form Page.

Step3.The CSE fill the inputs his/her required updated information.

Step4. The CSE click Update record button.

Step5.The system displays the updated customer information.


Post-condition The CSE must be click update record button and logout from the CSE page.

Table 2.2: Update customer record

Use case name Delete customer record

Use case number UC3

Description The customer service expert enables to select customer Delete link and

delete the customer.

Actor Customer service expert(CSE)

Pre-condition The CSE must login to the system by its own user name and password.


(Flow of event):

Step 1. The CSE wants to delete by selecting delete customer record

link.

Step2. The system Displays the customer delete form Page.

Step3. The CSE click delete link.

Step5.The system deleted customer information.


Post-condition The CSE must be click delete on required delete customer record and

logout from the CSE page.

Table 2.3: Delete customer record

Use case name Post Vacancy

Use case number UC4

Description The Administrator enables to select post vacancy link and fills the form

and submit to their record information and to view by any users.

Actor Administrator

Pre-condition The Administrator must login to the system by its own user name and



2006 E.C

password.


(Flow of event):

Step 1. The Administrator wants to post vacancy by selecting post

vacancy link.

Step2. The system Displays the post vacancy form Page.

Step3.The Administrator fills the form.

Step4. The Administrator click submit button.

Step5.The system displays the vacancy for any users.


Post-condition The Administrator must be click submit button and logout from the

administrator page.

Table 2.4: Post vacancy

Use case name Create account

Use case number UC5

Description Used to create account for users.

Actor Administrator

Pre-condition The user should be member of the KWSSO organization.


(Flow of event):

Step 1. The administrator selects create account link.

Step2. The system displays create account page.

Step3. The administrator fills the required information and submits it.

Step4. The system validates the information.

Step5. The system registers the users into the system.


Post-condition The account is successfully created.

Alternate course of

action:

A. Invalid information entry.

Go to step 2 to fill again.

Table 2.5: Create account

Use case name Record meter reading

Use case number UC6

Description The Bill officer enables to select record meter reading link and fills the

form and submit to their record information and view.

Actor Bill officer



2006 E.C

Pre-condition The Bill officer must login to the system by its own user name and

password.


(Flow of event):

Step 1. The Bill officer wants to record meter reading by selecting

record meter reading link.

Step2. The system Displays the record meter reading form Page.

Step3.The Bill officer fills the form.

Step4. The Bill officer click submit button.

Step5.The system displays the meter record for appropriate users.


Post-condition The Bill officer must be click submit button and logout from the

administrator page.

Table 2.6: record meter reading

Use case name Record maintain material

Use case number UC7

Description The Technical supervisor enables to select record maintain material

link and fills the form and submit to their record information and view.

Actor Technical supervisor (TSV)

Pre-condition The TSV must login to the system by its own user name and password.


(Flow of event):

Step 1. The Bill officer wants to record maintain material by selecting

record maintain material link.

Step2. The system Displays the record maintain material form Page.

Step3.The TSV fills the form.

Step4. The TSV click submit button.

Step5.The system displays the maintain material for appropriate users.


Post-condition The TSV must be click submit button and logout from the administrator

page.

Table 2.7: record maintain material



2006 E.C

Use case name View report



2006 E.C

Use case number UC8

Description The manager used to View report

Actor Manager

Pre-condition The data should be submitted in KWSSO database.


(Flow of event):

Step 1. The manager selects view activity link.

Step2. The system displays the View report page.

Step3. The manager press alternative view icon.

Step4. The system displays their data to manager from KWSSO

database.


Post-condition The employee activity is viewed by the manager.

Table 2.8: View report

2.7 System Requirement

The following are Functional and Nonfunctional requirements of the proposed new system that a

group member have identified from requirement use cases associated with each actor and use

case interactions.

2.7.1 Functional requirements

The functional requirement for the system describes the functionally or services that the system

is expected to provide. It is a system requirement that describes an activity or process that the

system must perform. The users first know how to use the system. The developed system is

expected to provide the following functionalities:

The proposed system will announce vacancy,

Generate customer bill,

The proposed system Allow customer to apply register for service,

The proposed system Allow customer to order request,

The proposed system Allow register maintenance material,

The proposed system will have authentication system for any level user like administrator

employee and other user’s indifferent way,

Enables users to view vacancy announcement,



2006 E.C

Hold customers personal information,

Displays new posted vacancy,

The proposed system will add data from different user of the system to the DB

Approve new customer’s application: support the record of the new customer to the

database if the organization adds more customers,

Modify customer data: modify the database if there is any change in the customer file.

The proposed system will search the customer file from the database,

2.7.2 Non-Functional requirements

Many non-functional requirements relate to the system as a whole rather than individual system

features. Nonfunctional requirements are behavioral properties that the system must have. The

following lists of nonfunctional requirements are expected from the system:

Scalability: The system must be compatible with any environment.

Security: should allow login to only authorized users

Reusability: Ability of an item that allows it to be used repeatedly unlike a disposable

item.

Performance: this system gives service 24 hours per day with maximum response time

so, it is easy to access data from the stored document.

Accuracy: proposed system will be better due to reduction of error. All operation can be

done correctly and it ensures that whatever information is coming from the data base is

accurate.

Reliability: The reliability of the proposed system will be better due to proper storage of

information when users access the application.

No Redundancy: In the proposed system can be avoided reputation of data anywhere in

the database.

Availability: All data in the system will be available all the time.

Efficiency: The system must ensure allocation and use of services being requested for the

users by using minimum memory storage, cost, time and human power.

User friendly Interface: Users can easily input and retrieve their profile and history.



2006 E.C

Error handling Exception: The system must recover immediately when a user enters

incorrect (error) data.

Efficient

o Searching a customer record should not take more time

o The system displays every window.

o The system should be user friendly.

o The system should operate as efficiently as possible.

Usability

o Usability is a term used to denote the ease with which people can employ a

particular tool or other human-made object in order to achieve a particular goal. In

this case our system possesses the following regarding to usability:

o Easier to learn—operation can be learned by observing the object

o More satisfying to use

Integrity

o Only authorized users of the system (administrator) can able to update, modify,

delete or access data. Access is denied for unauthorized and unauthenticated users

of the system.

Maintenance

o The system should be easy to maintain and update.



2006 E.C

CHAPTER THREE: OBJECT ORIENTED SYSTEM ANALYSIS

3.1 Introduction

The project development team used an object oriented system development methodology.

Because the Object system development approach gives easier way to break down problems into

simple and small components so that it reduces the vague appearance of the big problem. The

major activities covered in this chapter are constructing a use case model, documenting the use

case course of events, constructing sequence and activity diagrams and user prototype about the

proposed system.

3.2 Objective of system analysis

The new system changes the current working system and provide suitable graphical user

interface.

The main objectives of the system analysis are:

Filter the problem from the current working system

Find a solution for those potential problems.

To clarify the design and implementation phase.

It plays a major role in avoiding time wastage while designing.

It helps to see the internal functions of the current system and the new proposed system

clearly and completely.

3.3 System Requirement Specifications (SRS)

3.3.1 Use case diagram

Use Case represents interaction between the user and the system.

The following use cases have been identified from the system specification



2006 E.C

Use case

Login

Apply register for service

Maintain register

Payment register

Post vacancy

Delete vacancy

Update vacancy

Create account

Delete account

Update customer record

Delete customer record

Maintenance order

Process payment bill

Receive maintain

View report

Record meter reading

Post vacancy

Delete vacancy

Update Vacancy

The identified actors that will be participating in the system are:

Actors

Customer

Customer service expert

Technical supervisor

Administrator

Bill officer

Manager



2006 E.C

Bill officer

Customer

Customer Service Expert

Technical supervisor

Manager

Apply register for service

Maintenance order

View report

Update customer record

Delete customer record

Process Payment Bill

Delete payment

Delete maintenance

order

Receive maintain

Administrator

Creat account

Delete account

Login

<<includes>>

<<includes>>

<<includes>>

<<includes>>

<<includes>>

<<includes>>

<<includes>>

<<includes>>

<<includes>>

Post vacancy

Delete Vacancy

Update Payment

Record maintenance

material

<<includes>>

<<includes>>

<<includes>>

<<includes>>

Fig 3.1: UML Use case diagram

3.4 Use case documentation

The following consecutive tables show the use case documentation for each of the use cases that

has identified in the above use case diagram. Each table contains the use case name, the actor



2006 E.C

which initiates and interacts with the use case, description of the use case and typical course of

events that show the interaction between the actor and the use case which enable the team to

easily depict the functions of the proposed system.

Use case documentation for Login

Use case name Login

Description It allows user to login into the system

Actor/s Administrator, Bill officer, customer service expert, Technical

supervisor, manager.

Pre-condition The users should have registered into the system

Post-condition The user will login in to the system and able to access the required home

page.


(Flow of event):

Step 1. Initiated when the user wants to login into the system

Step2. The system Displays the User Login Page.

Step3.The user fill the inputs his/her user name and password.

Step4. The system verifies the username and password.

Step5.The system displays the appropriate home page.


From the above steps Step 1 and step 3 Actors action whereas Step 2

Step 4, Step 5 and Step 6 System response

Alternate course of

action:

The username/password is invalid.

1. The system displays error message.

2. The system continues at step 2 to fill user name and password again.

Table 3.1: Use case documentation for Login

Use case documentation for Create account

Use case name Create Account

Description Used to create account for users.

Actor Administrator

Pre- condition: The user should be member of the KWSSO



2006 E.C

Basic course of action (Flow

of event):

Step1.The administrator wants to create account.

Step2.The system displays create account page.

Step3.The administrator fills the required information and submits it.

Step4.The system validates the information.

Step5.The system registers the users into the system.

Step6.The system displays created account information.

Step7.The use case ends.

Post- condition The user account successfully created.

Alternative course of action

(Flow of event):

Invalid information entry.

1. The system displays error message.

2. Go to step 2 to fill again.

Table 3.2: Use case documentation for Create Account

Use case documentation for Delete account

Use case name Delete Account

Description It Allows Administrator to delete User account

Actor Administrator

Pre-condition To delete account the User account must be registered in the database.


(Flow of event):

Step1.The Administrator wants to delete account.

Step2.The system displays the delete account page.

Step3. The Administrator press on delete button.

Step4. The account is deleted from the system.

Step5. The system displays the remaining account.


From the above steps Step 1 and step 3 Actors action whereas Step 2


Alternative course of

action:

If the selected account is press delete link.

1. The system displays alternative message.

2. Go to step2 to select the delete account again.



2006 E.C

Table 3.3: Use case documentation for Delete Account

Use case documentation for Apply register for service

Use case name Apply register for service

Description It allows customer to register the DB, A customer requests registration by

using online application for KWSSO web page.

Actor Customer

Pre-condition The customer should have internet access and get the home page of KWSSO.

Post- condition The customer can join the organization and access online service from the

office.

Basic course of

action (Flow of

event):

Step1.Initiated when the Customer wants to register to the DB

Step2.Customer opens the home page and click apply register for register

link.

Step3.The system displays the Customer register page.

Step4.Enter the correct & all necessary information.

Step5. Initiate the system to sends to the organization.


From the above steps Step 1,Step 2, and step 4 Actors action whereas Step

3 Step 5 and Step 6 System response

Table 3.4: Use case documentation for Apply register for service

Use case documentation for Update customer record

Use case name Update customer record

Description It allows updating previously recorded customer data.

Actor Customer service expert

Pre-condition The customer must be registered & customer service expert login to the

system and the data of the customer should be ready.



2006 E.C


(Flow of event):

Step1. Customer service expert open the home page.

Step2. Customer service expert Enter login address on the login page.

Step3. The system check is the correct address or not.

Step4. Customer service expert enter customer ID of the intended

Customer.

Step5. The system validates the customer ID.

Step6. The system searches and display customer detail.

Step7. Customer service expert enter new modification.

Step8. System updates the information and displays it.

Step9. End use case.

From the above steps Step 1,Step 2, Step 4, and Step 7 Actors action

whereas Step 3, Step 5, Step 6, Step 8, and Step 9 System response

Post- condition The customer service expert will have updated customer data.

Table 3.5: Use case documentation for Update customer record

Use case documentation for Delete customer record

Use case name Delete customer record

Description It allows removing customer from KWSSO database.

Actor Customer service expert

Pre-condition The customer must be registered & customer service expert login to the

system.

Post- condition The customer service expert will have deleted customer or The

customer will be discarded from the system database.


(Flow of event):

Step1. Customer service expert open the home page.

Step2. Customer service expert Enter login address on the login page.


Step4. Customer service expert enter customer ID of the intended

Customer.

Step5. The system validates the customer ID.

Step6. The system searches and display required customer.

Step7. The system deletes the customer.



2006 E.C

Step8. End use case


whereas Step 3, Step 5, Step 6, Step 7, and Step 8 System response

Table 3.6: Use case documentation for Delete customer record

Use case documentation for Order maintenance

Use case name Order maintenance

Description It allow customer to order maintenance request.

Actor Customer

Pre-condition The customer initiated to order maintenance request.

Post- condition Maintenance order will be recorded to the system.


(Flow of event):

Step1. Customer open the homepage

Step2. Customer selects maintenance order form from the home page.

Step3. The customer enters their ID.

Step4. System validates the customer ID.

Step5. The customer enters maintenance detail in the form.

Step6. The system responses view its own request and the other

customer request list to the customer.

Step7. End use case


whereas Step 4, Step 6, and Step 7 System response

Table 3.7: Use case documentation for Order maintenance

Use case documentation for Receive maintenance

Use case name Receive maintenance

Description It allows receive and approve customer maintenance order process.

Actor Technical supervisor.

Pre-condition The customer should order the maintenance.

Post- condition Customer maintenance order should be transferred and service being

delivered.



2006 E.C


(Flow of event):

Step1.Technical supervisor open the homepage

Step2. Technical supervisor insert the login address on the page.

Step3. System validates the address.

Step4. Technical supervisor checks and see the problem.

Step5. Technical supervisor take the order from the customer.

Step6. End use case

From the above steps Step 1,Step 2, Step 4 and Step 5 Actors action

whereas Step 3, and Step 6 System response

Table 3.8: Use case documentation for Receive maintenance

Use case documentation for View report

Use case name View report

Description It allows View report from different employee.

Actor Manager

Pre-condition They should have prepared data by the employee of the organization

and customer.

Post- condition The manager sees the View report prepared by the office employees.


(Flow of event):

Step1. The manager opens the home page.

Step2. The manager Enter his/her user name and password.


Step4. The manager View report.


From the above steps Step 1,Step 2 and Step 4 Actors action

whereas Step 3, and Step 5 System response

Table 3.9: Use case documentation for View report

Use case documentation for Process payment bill

Use case name Process payment bill

Description The system calculates the cost of bill.

Actor Bill officer

Pre-condition The Bill officer should get the current water meter reading value of the



2006 E.C

customer.

Post- condition The customer bill will be calculated.


(Flow of event):

Step1. Bill officer Open the homepage.

Step2. Bill officer Enter user name and password.

Step3. System validates it.

Step4. Bill officer Enter current water meter reading of the customer and

other important information.

Step5. Initiate the system to calculate the cost.

Step6. End use case

From the above steps Step 1,Step 2 and Step 4 Actors action whereas


Table 3.10: Use case documentation for process payment bill

Use case documentation for Record meter reading

Use case name Record meter reading

Description The bill officer reads water meter reading.

Actor Bill officer

Pre-condition Bill officer should have collected reading.

Post- condition The current meter reading of the customer will recorded.


(Flow of event):

Step1. Bill officer Open the homepage.

Step2. Bill officer should collect water meter.

Step3. Bill officer Enter the address.


Step5. System retrieves the customer ID & customer detail.

Step6. Bill officer Enter the current reading to the system.


From the above steps Step 1,Step 2, Step 3 and Step 6 Actors action

whereas Step 4, Step 5 and Step 7 System response.

Table 3.11: Use case documentation for Record meter reading

Use case documentation for Post vacancy



2006 E.C

Use case name Post vacancy

Description Administrator used to post vacancy.

Actor Administrator

Pre-condition Administrator first login to the system.

Post- condition Posted vacancy viewed by all users of the system


(Flow of event):

Step1. Administrator Open the homepage.

Step2.Administrator login to the system.

Step3. Administrator click on post vacancy link.

Step4. Administrator fills the post vacancy form.

Step5. Administrator click submit button.


Table 3.12: Use case documentation for Post vacancy

Use case documentation for Delete Vacancy

Use case name delete Vacancy

Description It allows removing post vacancy from KWSSO database.

Actor Administrator

Pre-condition The Vacancy must be registered into DB & Administrator login to the

system.

Post- condition The Administrator will have deleted vacancy or The posted vacancy

will be discarded from the system database.


(Flow of event):

Step1. Administrator opens the home page.

Step2. Administrator Enter login address on the login page.


Step4. Administrator click delete vacancy link.

Step5. The system deletes the vacancy.

Step6. End use case

Table 3.13: Use case documentation for Delete post vacancy

Use case documentation for record maintain material



2006 E.C

Use case name Record maintenance material

Description It allows material to register the database.

Actor Technical supervisor.

Pre-condition Technical supervisor first login using its own username and password

Post- condition Technical supervisor register the material into KWSSO database

Basic course of

action (Flow of

event):

Step1. Technical supervisor open the home page.

Step2. Technical supervisor enter its own username and password to login.

Step3. Technical supervisor click the record maintenance material link.

Step4.Enter the correct & all necessary information.

Step5. Initiate the system to sends to the organization.


Table 3.14: Use case documentation for record maintain material

3.5 Sequence diagram

A sequence diagram in a unified modeling language (UML) is a kind of interaction diagram that shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart. A sequence diagram shows object interactions arranged in time sequence. [2]



2006 E.C

Apply register

Customer<<actor>>

Wants to register

Validate

Customer register<<link>>

KWSSO<<DB>>

Customer register<<UI>>

Customer register <<controller>>

Display

Customer enter detail information

If invalid

If valid

Validatesuccessfully register

Fig 3.2: UML Sequence diagram for Customer Apply Register for service



2006 E.C

View Different Activity

Manager<<actor>>

View activity<<controller>>

View activity<<link>>

Want to view Create

View module page<<UI>>

Display

Fill and press view

validate

If invalid

KWSSO<<DB>>

If valid

confirmationThe activity is viwed

Fig 3.3: UML Sequence diagram for different activity



2006 E.C

Update customer

Customer service expert<<actor>>

Update customer <<link>>

Update customer<<controller>>

Update customer<<UI>>

Want to update custom

CreateDisplay

Modify and update

KWSSO<<DB>>

validate

If invalid

If valid

Successfully updated

Confirmation

Fig 3.4: UML Sequence diagram for Update Customer record



2006 E.C

Customer <<actor>>

Order maintenance

Order maintain <<link>>

Order maintain <<UI>>

Order maintain <<controller>>

KWSSO <<DB>>

Wishis to order maintain

Create

Display

Fill and submit

If invalid

validate

If valid

Success

confirmation

Fig 3.5: UML Sequence diagram for Order Maintenance



2006 E.C

Delete customer

Customer service expert <<actor>>

Wants to delete

validate

KWSSO<<DB>>

Delete customer <<UI>>

Delete customer <<controller>>

Delete customer <<link>>

Creates

Display

Delete customer

If invalid

If valid

Successfully deleted

confirmation

Fig 3.6: UML Sequence diagram for Delete customer record



2006 E.C

Receive maintain

Technical supervisor <<actor>>

Wants to receive

validate

Receive maintain<<UI>>

Receive maintain<<controller>>

Receive maintain<<link>>

Create

Display

Receive maintain

If invalid

If valid

KWSSO<<DB>>

ConfirmationReceive maintain

Customer Maintain

Cheack ()

Customer

Take maintain order

Fig 3.7: UML Sequence diagram for Receive Maintenance



2006 E.C

Create account

Administrator<<actor>>

Wants to create

Create account<<link>>

Create account<<conroller>>

KWSSO<<DB>>

Create account<<UI>>

CreateDisplay

If invalid

Validate

If valid

Confirmation

Success

Fig 3.8: UML Sequence diagram for Create account



2006 E.C

Delete account

Administrator<<actor>>

Wants to delete

Delete account<<link>>

Delete account<<conroller>>

KWSSO<<DB>>

Delete account<<UI>>

CreateDisplay

Delete accoun

If invalid

Validate

If valid

Confirmation

Success

Fig 3.9: UML Sequence diagram for Delete account



2006 E.C

Login

User<<actor>>

Wants to Login

Validate

Login<<UI>>

Login <<controller>>

Login<<link>>

KWSSO<<DB>> Main page

Display

Display

If invalid

If valid

If not authonticated

If authonticated

ConfirmationSuccess

Fig 3.10: UML Sequence diagram for Login



2006 E.C

Water record

Bill officer <<actor>>

Wants to record

Validate

Record water meter<<controller>>

Record water meter <<link>>

create

Record water meter<<UI>>

create

If invalid

If valid

KWSSO<<DB>>

ConfirmationSuccess

insert record

Fig 3.11: UML Sequence diagram for water record



2006 E.C

3.6 Activity diagram

An Activity diagram is similar to a flowchart to represent the flow from one activity to another

activity. Activity diagrams and State chart diagrams are related. While a State chart diagram

focuses attention on an object undergoing a process (or on a process as an object), an Activity

diagram focuses on the flow of activities involved in a single process. The Activity diagram

shows how these single-process activities depend on one another. [5]

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.

Customer open home page

Click apply register link

Enter all necessary information

Click register button

Apply register

Fig 3.12: UML activity diagram for Apply Register for service for service



2006 E.C

Login Administrative staff

Employee of the office open the home page

Employee select login alternative

Employee Enter uname and pwd

InvalidDisplay error message

User login to the system

valid

Fig 3.13: UML activity diagram for Login administrative staffs



2006 E.C

View different activity

The manager open the homepage

The manager enter the login address

Manager select its own login alternative

Display Error message

View the prepared different activity

valid

Invalid

Fig 3.14: UML activity diagram for View report



2006 E.C


Bill officer should collect water meter

The bill officer open the homepage

Bill officer select its own login alternative

invalid Display Error message

System retrives the customer ID and customer detail

Valid

Bill officer see and put the curent reading

Fig 3.15: UML activity diagram for Record meter reading



2006 E.C

Calculating bill

Bill officer Login to the system

Bill officer select its own login alternative

Display Error messageInvalid

Valid

Enter current water meter reading

Enter necessary information of the customer

System calculates Bill

Fig3.16: UML activity diagram for Process payment bill



2006 E.C

Receive maintenance

Technical supervisor Enter the address on the page

Errer message

Technical supervisor Enter the customer ID

Correct address

Incorrect Address

System display the customer detail and their order

Incorrect ID

Correct ID

Technical supervisor see the problem and receive it

Fig 3.17: UML activity diagram for Receive maintenance



2006 E.C

Order maintenance

Customer selects maintenance order form

The Customer Enters ID

The Customer Enters maintenance detail in the form

System respond success message to the customer

Correct ID

Incorrect ID

Fig 3.18: UML activity diagram for Order maintenance



2006 E.C

Create account

Select create account link

Fills the information and submit

Display Error message

The account is created

Valid

Not Valid

Fig 3.19: UML activity diagram for Create account



2006 E.C

Delete account

Select the user wants to delete

Display delete account link table

press delete link on required account

Select the type wants to delete

The account is deleted from the DB

Cancel

Ok

Display alternative message

The account is deleted from the DB

Fig 3.20: UML activity diagram for Delete account



2006 E.C

Delete customer

Customer service expert Login to the customer service page

Customer service expert Enters customer ID want to delete

Delete Customer

Incorrect

Correct

Incorrect

Correct

Fig 3.21: UML activity diagram for Delete customer record



2006 E.C

Customer service expert Login to the customer service page

Update customer

Customer must be registered

Customer service expert Enter customer ID of the intended customer

Customer service expert Enter new modification

Correct ID

Incorrect ID

Incorrect

Correct

Fig 3.22: UML activity diagram for Update customer record



2006 E.C

Administrator open home page

Administrator login to the system select its login alternative

Fills the form and submit the vacancy

Click post vacancy link

Post vacancy

Invalid

Valid

Fig 3.23: UML activity diagram for post vacancy



2006 E.C

3.7 User interface prototype

User interface prototyping is an iterative development technique in which users are actively

involved in the mocking-up of the UI for a system. [11]

Home page

Bill officerTechinical supervisor

Login

Customer service expert

ManagerAdministrator Customer


Delete account

Create account

Update customer

Delete customer


Receive maintain

Calculate cost of Bill

Apply register

Maintain order

HomeHomeHomeHomeHomeHome

Update vacancy

Delete Vacancy

Post Vacancy

view Payment

View Payment

View Vaccancy

View Vaccancy

Record Material

View Vaccancy

Fig 3.24: User interface prototype



2006 E.C

CHAPTER FOUR: SYSTEM DESIGN

4.1 Introduction

This chapter mainly concerned with the design part of customer service management system. In

order to make the implementation easy the design is very important.

In this chapter we will see the different type of class type architecture such as user interface

layer, process/control layer, business/domain layer, persistence layer and system layer and also

different types of system modeling techniques that are used for the implementation of the system

such as class modeling, state chart modeling and also some system design techniques such as

user interface design are also to be covered in this chapter.

Generally this chapter is describes how the project is designed, what tasks done under this

project.

4.2 Class Type Architecture

Class type architecture provides a strategy for layering the classes of the system to distribute the

functionality of the software among classes. Furthermore, class type architectures provide

guidance as to what other types of classes a given type of class will interact with, and how that

interaction will occur. This increases the extensibility, maintainability, and portability of the

systems. [4]

Interface This layer wraps access to the logic of our system. This layer consists of interface

Class – user interface (UI) classes that provide people access to our system.

Domain- This layer implements the concepts pertinent to our business domain, focusing on the

data aspects of the business objects, plus behaviors specific to individual objects.

Process- The process layer implements business logic that involves collaborating with several

domain classes or even other process classes.

Persistence- Persistence layers encapsulate the capability to store, retrieve, and delete

objects/data permanently without revealing details of the underlying storage technology.



2006 E.C

System- System classes provide operating-system-specific functionality for your applications,

isolating your software from the operating system (OS) by wrapping OS-specific features,

increasing the portability of your application.

KWSSO

Data source

Persistence(Data)

Domain(Business)

Process(Application,controller)

Interface(User interface,System interface)

System(Infrastructure,Platform)

Figure 4.1: Class type architecture



2006 E.C

4.3 Class modeling

Class diagrams in the Unified Modeling Language (UML) 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 the classes. The class diagram with its

corresponding objects will be present in the following diagram. [4]

Administrator

- First_name: varchar- Last_name: varchar- Pass word: varchar- User_name: varchar- Email: varchar

+Create Account()+Delete Account()+Update Account()+Post Vaccancy()+Delete Vaccancy()+ Login()

Customer

- First_name: varchar- Last_name: varchar- Request:varchar- Email: varchar- Customer_Id :varchar- Telephone:int- Catagory:varchar

+ Maintainance Order()+ Apply Register()+ View Payment()+ View Vaccancy()

CSE

- First_name: varchar- Last_name: varchar- Email: varchar- Password :varchar- User_name:varchar

+ Delete Customer()+ Update customer()+ View Payment()+ Login()

TSV


+ Receive maintain()+ Reject order()+ Register material()+ Delete material()+ Update material()+ View Vaccancy()+ Login()

Manager


+ View report()+ view Payment()+ View Vaccancy()+ Login()

Bill Officer


+ Register meter reading()+ Delete meter reading()+ Update meter reading()+ View meter reading()+ Genereating Bill()+ View Vaccancy()+ Login()

Vaccancy

- Qualification: varchar- work Experiance: varchar- Required_no: varchar- Place of work :varchar- Departement:varchar- Date of application:varchar

*

1

*

1

*

1

1

1

1

1

1

1

1

*

1

1

1

*

*

1

*

1

Fig 4.2: Class diagram


http://en.wikipedia.org/wiki/Class_(computer_science)

http://en.wikipedia.org/wiki/Unified_Modeling_Language


2006 E.C

4.4 State chart modeling

The state chart diagram is shows the change of an object through time from one state to the other

state. State chart modeling is used to show 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. The following figure shows the state of the objects. [7]


Fig 4.3: State chart diagram for login

Confirmation Order Action

Finish

CancelInitial

TransitionIntermediate state

State objectInitialization

Display the required page

Check the validate of Input

Fill user name and passwordLogin eventIdle


2006 E.C


Fig 4.4: State chart diagram for Update payment


Finish

Cancel

Initial object

TransitionIntermediate stateState objectInitialization

Update payment into DB and view


Fill the formUpdate payment

Idle


2006 E.C


Fig 4.5: State chart diagram for record meter reading


Finish

Cancel

Initial object


Register meter reading and view the record


Fill the formRecord meter reading event

Idle


2006 E.C


Fig 4.6: State chart diagram for Material register


Finish

Cancel

Initial object

Transition

Intermediate stateState object

Initialization

Register the material and view


Fill the formMaterial register event

Idle


2006 E.C


Fig 4.7: State chart diagram for Customer register


Finish

Cancel

Initial object



Register customer, View the customer ID and detail information


Fill the formCustomer register event

Idle


2006 E.C


Fig 4.8: State chart diagram for view report


Finish

Cancel

Initial object



View the different activity


Fill user name and passwordView reportIdle


2006 E.C


Fig 4.9: State chart diagram for post vacancy


Finish

Cancel

Initial object



Post and view Vacancy


Fill the formPost vacancy eventIdle


2006 E.C


Fig 4.10: State chart diagram for create account


Finish

Cancel

Initial object


View created account


Fill the formCreate account event

Idle


2006 E.C

4.5 Component Modeling

Component diagrams show how the physical components of a system are organized. And also

shows which component or objects will be accessed by whom and what type of security

infrastructures it is using. The diagram is simulated below.

TSV

Apply registerCustomer

CSE

View Vaccancy

Register Maintain Material

Update Customer

Delete customer

Bill Officer

AdministratorPost Vaccancy

Payment record

Manager


Security Login

Persistence

KWSSO<<Database>>

Fig 4.11: Component Modeling



2006 E.C

4.6 Deployment modeling

Deployment modeling is used to show the hardware of the system, the software that is installed

in the hardware and also shows how the software and the hardware components work together.

[3]

Users Computers

Web browsers

MozilaFirefox

Web Server

Xampp

Application

Create Account

Generate bill

Post Vaccancy

Payment record

Database server

KWSSO Database

PHP MYSQL

Fig 4.12: deployment Modeling



2006 E.C

4.7 User Interface design

User interface design is the overall process of designing how a user will be able to interact with a

system. [6]

The goal of user interface design is to make the user's interaction as simple and efficient as

possible, in terms of accomplishing user goals.

Kombolcha

Water Supply Office Customer Service Management SystemHome Users Information Feedback Customer About Us Contact As Login

Copy right @20014 Customer service managenment System

Fig :4.13 Home page



2006 E.C

Fig :4.14 login form UI

Fig :4.15 Create accounte form UI


Login

User Name

Password

Login Reset

Create Account

First Name:

Last Name:

Email:

Password:

Re_EnterPassword:

User Name:

Submit Reset

Customer Registration

Date:

First Name:


2006 E.C

Fig :4.16 Customer Register form UI

Fig :4.17 Update Delete Account form UI


Customer Registration

Date:

First Name:

Submit Reset

Delete & Update Account Form

Record_no Action

First name

Last name

Email password

Reenter password

User name

Update Delete

Search for Customer Record

Enter Customer ID


2006 E.C

Fig :4.18 Search Customer UI

Fig :4.19 Delete Update Customer record form UI

Fig :4.20 Register maintain material form UI


Search for Customer Record

Enter Customer ID

Submit

Delete or Update Customer record

Customer ID

Action Date

First name

Last name

Email Request

Phone

Category

House No

Kebele City

Meter size

Update Delete

Resource recording

Material Name:

Material Price:

Material Size:

Material Photo:

Status:

Submit Reset

Delete/Update resource recording

Material ID Action Material Name Material Price Material Size Material Photo StatusUpdate Delete


2006 E.C

Fig :4.21 Delete update maintain material

Fig :4.22 Search maintain material UI

Fig :4.23 Search payment UI


Delete/Update resource recording

Material ID Action Material Name Material Price Material Size Material Photo StatusUpdate Delete

Search resource

Enter Material ID Submit

Bill processing

Customer ID:

First Name:

Last Name:

Category:

View customer payment bill

Enter Customer ID Submit


2006 E.C

Fig :4.24 Payment register form UI


Bill processing

Customer ID:

First Name:

Last Name:

Category:

Submit Reset

Delete or Update outdated Vacancy

Record No

Action No Qualification

Experience Required Place Department

Date of Application

Detail

Update Delete


2006 E.C

Fig :4.25 Delete update vaccancy

Fig :4.26 Post vaccancy form UI

CHAPTER FIVE: IMPLIMENTATION

5.1 System Implementation

Implementation is the phase where objectives of physical operations of the system turned into

reality i.e. real working model. The crucial phase in the system development life cycle is the

successful implementation of the new system design. The process of converting as new system


Post Vacancy Form

Number:

Qualification:

Work Experience:

Required No:

Place of work:

Department:

Date of Application:

Submit Reset


2006 E.C

into an operational one is known as system implementation. This includes all those activities that

take place to convert from an old system to a new system.

Fig 5.1: home page



2006 E.C

Fig 5.2: Customer page



2006 E.C

Fig: 5.3 Order Request form

Fig: 5.4 Bill generate form



2006 E.C

Fig 5.5: Administrator page

Fig: 5.6 Admin login form



2006 E.C

Fig 5.7: Bill officer page



2006 E.C

Fig 5.8: Technical supervisor page

Fig: 5.9 Technical supervisor login



2006 E.C

Fig 5.10: Customer service expert page



2006 E.C

Fig 5.11: Manager Page

5.2 CodingFirst phase of implementation is coding. Coding is the process whereby the physical design

specification created by the designers is turned in to working computer code by the programmer.

Modern language that used is Hypertext Preprocessor (PHP). [11]

The code is made simple in such a way that another programmer can easily understand and work

on that in future.

Sample code for create database and table created

<?php

mysql_connect("localhost","root","");

mysql_query("create database if not exists water44") or die(mysql_error());



2006 E.C

mysql_select_db("water44"

);

mysql_query("CREATE TABLE IF NOT EXISTS `Comment` (

`record_no` int(30) NOT NULL AUTO_INCREMENT,

`name` varchar(30) NOT NULL,

èmail` varchar(30) NOT NULL,

`comment` varchar(1000) NOT NULL,

PRIMARY KEY (`record_no`)

)");

mysql_query("CREATE TABLE IF NOT EXISTS `Creataccountadmin`(


`first_name` varchar(20) NOT NULL,

`last_name` varchar(20) NOT NULL,


`password` varchar(20) NOT NULL,

`re_password` varchar(20) NOT NULL,

ùser_name` varchar(20) NOT NULL,


)");



2006 E.C

mysql_query("INSERT INTO `Creataccountadmin` (`record_no`,`first_name`, `last_name`,

èmail`, `password`, `re_password`,ùser_name`) VALUES ('1', 'alex', 'man', '[email protected]',

'aaaaaa','aaaaaaa', 'admin'), ('2', 'adamu', 'man', '[email protected]', '111111','111111', 'adamu')

;");

mysql_query("CREATE TABLE IF NOT EXISTS `Registercustomer` (

ìd_no` int(30) NOT NULL AUTO_INCREMENT,

`date` date NOT NULL,




`request` varchar(30) NOT NULL,

`phone_number` varchar(30) NOT NULL,

`catagory` varchar(30) NOT NULL,

`house_number` varchar(2) NOT NULL,

`kebele` varchar(30) NOT NULL,

`city` varchar(30) NOT NULL,

`metre_size` varchar(30) NOT NULL,

PRIMARY KEY (ìd_no`)

)");

mysql_query("CREATE TABLE IF NOT EXISTS `Payment` (

ìd_no` int(30) NOT NULL,



2006 E.C




`day` varchar(30) NOT NULL,

`mounth` varchar(30) NOT NULL,

`year` varchar(30) NOT NULL,

`mete_size` varchar(2) NOT NULL,

`previous_record` varchar(30) NOT NULL,

`current_record` varchar(30) NOT NULL,

`difference` varchar(30) NOT NULL,

`birr` varchar(30) NOT NULL,

PRIMARY KEY (ìd_no`)

)");

mysql_query("CREATE TABLE IF NOT EXISTS `Vaccancy` (


`number` int(30) NOT NULL,

`qualification` varchar(30) NOT NULL,

`work_experiance` varchar(30) NOT NULL,

`required_no` int(30) NOT NULL,

`place_work` varchar(30) NOT NULL,



2006 E.C

`departement` varchar(30) NOT NULL,

`date` varchar(30) NOT NULL,

`detail` varchar(30) NOT NULL,


)");

mysql_query("CREATE TABLE IF NOT EXISTS `material` (

`material_no` int(30) NOT NULL AUTO_INCREMENT,

`material_name` varchar(30) NOT NULL,

`material_price` varchar(30) NOT NULL,

`material_size` varchar(30) NOT NULL,

`status`varchar(30) NOT NULL,

PRIMARY KEY (`material_no`)

)");

mysql_query("CREATE TABLE IF NOT EXISTS `Creataccountbillofficer`(





`password` varchar(20) NOT NULL,

`re_password` varchar(20) NOT NULL,

ùser_name` varchar(20) NOT NULL,



2006 E.C


)");

mysql_query("INSERT INTO `Creataccountbillofficer` (`record_no`,`first_name`, `last_name`,

èmail`, `password`, `re_password`,ùser_name`) VALUES ('1', 'alex', 'man', '[email protected]',

'aaaaaa','aaaaaaa', 'bill'), ('2', 'adamu', 'man', '[email protected]', '111111','111111', 'bill')

;");

mysql_query("CREATE TABLE IF NOT EXISTS òrderrequest` (


ìd_no` int(30) NOT NULL,



`request` varchar(30) NOT NULL,

`phone_number` varchar(30) NOT NULL,


`house_number` varchar(2) NOT NULL,

`kebele` varchar(30) NOT NULL,

`city` varchar(30) NOT NULL,

`metre_size` varchar(30) NOT NULL,

`Description` varchar(1000) NOT NULL,


)");



2006 E.C

?>

5.3 TestingThe final phase of implementation is testing. Testing is a process to show the correctness of the

program. Testing is checking of the system workability in an attempt to discover errors and

avoiding such errors from the system. In this the team members tested the entire system as a

whole with all forms, code, modules. In this we tested all the functionalities in the system. All

errors in the forms, functions, modules have been tested. The following are different testing

strategies.

5.3.1 Unit TestingUnit testing is every module of the system is separately tested. It is often done by the

programmer to test that the unit he/she has implemented is producing expected output against

given input.

Test Case1Unit to Test = Create AccountAssumptions = The user account is createdTest Data = First name (empty ,invalid First name, Valid First name) Last name (empty ,invalid Last name, Valid Last name) Email( empty, invalid email, valid email) Password (empty. Invalid Password, valid Password) Reenter password (empty. Invalid Password, valid Password) Username ( empty ,Invalid Password, Valid Password)

Steps to be Executed Data Expected Results

Empty First name and Click submit button

Any valid data for the other fields “Please Enter First Name!”

Invalid First name and Click submit button

First name= Abebe123Any valid data for the other fields

“Invalid First Name!b/c it may be Enter number”.

Enter Valid First name, empty Last Name and Click submit button

First name= AbebiAny valid data for the other fields

“Please enter Last Name name!”

Enter Valid First name , invalid Last Name and Click submit button

First name= AbebiLast Name=-belay4Any valid data for the other fields

“Invalid Last Name!b/c it may be Enter number”.

Enter Valid First name and Last Name, empty Email and Click submit button

First name= AbebeLast Name=belayAny valid data for the other fields

“Please Enter Email!”

Enter Valid First name, and First name= Abebe “invalid Enter! Please Enter Like



2006 E.C

Last Name, invalid Email and Click submit button

Last Name=belayEmail address=alexyahoo.comAny valid data for the other fields

[email protected]!”

Enter Valid First name, Last Name and Email, empty Password and Click submit button

First name= AbebeLast Name=belayEmail [email protected] valid data for the other fields

“Please Enter password”

Enter Valid First name, Last Name, Email and, invalid password and Click submit button

First name= AbebeLast Name=belayEmail [email protected]=123Any valid data for the other fields

“Password is too short!! it must contains atlist 6 character”

Enter Valid First name, Last Name and Email, Password ,empty Reenter Password and Click submit button

First name= AbebeLast Name=belayEmail [email protected]=123456Any valid data for the other fields

“Please confirm password”

Enter Valid First name, Last Name and Email, Password ,invalid Reenter Password and Click submit button

First name= AbebeLast Name=belayEmail [email protected]=123456Reenter password=12345rAny valid data for the other fields

“ Password does not match”

Enter Valid First name, Last Name, Email, Password, Reenter Password and empty Username and Click submit button

First name= AbebeLast Name=belayEmail [email protected]=123456Reenter password=123456Any valid data for the other fields

“please enter user_name”

Enter Valid First name, Last Name, Email, Password, Reenter Password and invalid Username and Click submit button

First name= AbebeLast Name=belayEmail [email protected]=123456Reenter password=123456User Name=eeAny valid data for the other fields

“user_name is too short!! it must contains atlist 3 character”

Enter Valid First name, Last Name, Email, Password, Reenter Password and Username and Click submit button

All fields Fulfill with valid data “The user account is created”

Table 5.1: Test Case1: for Create Account


mailto:%20address%[email protected]%20


2006 E.C

5.3.2 System TestingIt 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. In this the team members tests all the functionalities in the System. All errors in the forms, functions, modules are tested.

Hardware and software acquisitions for Implementation

For the project implementation, the following hardware and Software’s are used.

Hardware:- Printer: For printing Documentation Computers Flash Disk(4 GB)

Software:-

Microsoft office 2010 Macromedia Dreamweaver Wamp server Firefox browser Adobe photo shop

5.4 User manual preparation In order to access the system, first of all every user must have an account or permission from

administrator; except customer, customer can access the page simply. So administrator should

have to create an account for every user like Customer Service Expert, Manager, Technical

supervisor, Bill officer and itself. Users should enter to the system parts by using their individual

User Name and password. These User Name and password is created by the administrator.

Finally the user can access the system by their current ID and Password.

CHAPTER SIX: CONCLUSIONS AND RECOMMENDATION

6.1 ConclusionsThe Web Based Customer Service Management System for kombolcha water supply service

office (KWSSO) process made computerized to reduce human errors and to increase the

efficiency. The main focus of this project is to lessen human efforts. The maintenance of the



2006 E.C

records is made efficient, as all the records are stored in the database, and also data can be

retrieved easily. The editing is also made simpler. The user has to just type in the required field

and press the update button to update the information.

The customer is given a particular unique id number. So that they can be accessed the system

correctly by his/her ID without errors. Our main aim of the project is to get the correct

information about a particular customer and give some of the information and service needed for

the customer and make it more profitable than the previous desktop system by:

Reduce the number of employee

Minimize the time required to perform task

Minimize the work load of employees

Increase employee satisfaction

6.2 RecommendationThe system we have developed is an application web based system it needs a skilled person to

work with the system. So, we recommend the system should be required the responsible and

skilled person. We highly recommend the system should be kept in highly safe and favorable

condition.

As a new system developer,we recommend the following functionalities are more done such as:- Registration new customer Post vacancy



2006 E.C

The Web Based Customer Service Management System for kombolcha water supply service

office (KWSSO) has implemented most of the services of the office. However, there are some issues

that need further investigation and we recommend them as future work. These include the following:

Employee management

Pay rolling and the likes

References1. http://en.wikipedia.org/

2. http://en.wikipedia.org/wiki/Sequence_diagram

3. http://www.tutorialspoint.com/

4. http://en.wikipedia.org/

5. http://creately.com/blog/

6. http://edutechwiki.unige.ch/

7. http://www.tutorialspoint.com/


http://edutechwiki.unige.ch/

http://creately.com/blog/

http://en.wikipedia.org/wiki/Class_diagram

http://en.wikipedia.org/wiki/Sequence_diagram

http://en.wikipedia.org/wiki/Class_diagram


2006 E.C

8. https://www.youtube.com/

9. http://stackoverflow.com/

10. books, Newspaper and employee interview

11. http://www.ambysoft.com/l

12. Bell. D. (2000).Software engineering a programming Approach. (3rd edition)USA:

Pearson Education limited

13. Beginning PHP5, Apache, MySQLWeb Development, Waley publishing, Inc

14. PHP5 and MySQL® Bible, Tim Converse and Joyce Park with Clark Morgan, Inc


http://www.ambysoft.com/l

http://stackoverflow.com/questions/3082197/blink-tag-not-afftect-on-ie-all-version

https://www.youtube.com/watch?v=ObNDfHliVdw

Date post:	17-Jan-2016
Category:	Documents
Upload:	shemsedin-shukre
View:	212 times
Download:	0 times

KWSSO water44

Documents