DESIGN AND IMPLEMENTATION OF DEBRE MARKOS

WATER AND SEWERAGE SERVICE

WATER BILLING MANAGEMENT SYSTEM PROJECT
Department of Computer science

Submitted by

Tewachew Adego____________CS/045/2010

Ayenew Shiferaw ______________CS/007/2012

Gebeyehu Deres ____________CS/008/2010

Helen Belete _____________ CS/056/2010

In partial fulfillment for the award of the degree of

BACHLOR OF SCIENCE IN COMPUTER SCIENCE

ADVISOR NAME: Amare D

……………

DEPARTMENT OF COMPUTER SCIENCE

Dima Technology collage

Debre markos, Ethiopia
March 2013

1
 Declaration
This is to declare that this project work is done under the supervision of Instructor Amare D. Project
advisor, and having the title DESIGN AND IMPLEMENTATION OF DEBRE MARKOS WATER
AND SEWERAGE SERVICE WATER BILLING MANAGEMENT SYSTEM contribution of:

Name Signature
1. Tewachew Adego ………………
2. Ayenew Shiferaw ……………….
3. Gebeyehu Deres ………………..
4. Helen Belete ………………..
No part of the project work has been reproduced illegally (copy and paste) which can be considered
as plagiarism. All referenced part has been used to argue the idea and have been cited properly. The
project team will be responsible and liable for any consequence if violation of this declaration is
proven.

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

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

Name of Advisor Signature

i
 Acknowledgment

At the outset, we thank God almighty for making my endeavor a success. We would
like to acknowledge the support of the Debre markos City Water Supply Service. They
have given the required all documents essential for the study. We also would like to express the
deepest appreciation to our advisor Mr. Amare D. who has supported us his valuable comments
and corrections. He encouraged us to pursue on this topic and spent extra time by helping our
group to accomplish our study. Finally, we also appreciate the help and support from all persons
who were directly or indirectly involved in our project.

ii
 ABSTRACT
The principal objective of this paper is to demonstrate and automate the capability in Debre
Markos water and sewerage service / DMWSS/ to conduct effective, automated, accurately,
and inexpensively.

The need for electronically controlled service, in the absence of customer to ensure constant
and effective service distribution is a serious demand. We therefore intend to provide a
solution by constructing an electronic system that has the capability of monitoring the service
of the organization to the customers and at the same time supply Registration and other
related service to the customer when they need to access.

The project involves methods like data/requirement collection, system analysis and
design(object oriented approach).It also includes the use of hardware and software’s like
operating system, DBMS ,application software, PhpMyAdmin and the likes. DBMS for the
purpose of database implementation, Application software’s to develop user and
administrative interface, PhpMyAdmin to providing the user with an interface. From this
project, we hope to build automatically effective and efficient system for DMWSS.

iii
List of Acronyms
CMS: - Customer management system.

CSS: - Cascading style sheet.

DBMS: Database management system.

DMCWSOCSMS: Debre Markos City water supply office customer service management system.

DMWSS: Debre Markos water and sewerage service.

HDD:- hard disk deriver.

HTML: - Hypertext markup language.

MYSQL: - My Structured Query Language.

OOD: - object oriented design.

PHPMYADMIN: Hypertext Pre Processor

iv
Table of Content

s
Acknowledgment...............................................................................................................................................ii
ABSTRACT.....................................................................................................................................................iii
List of Acronyms..............................................................................................................................................iv
List of Figures.................................................................................................................................................vii
1. INTRODUCTION...................................................................................................................................1
1.1. Background..........................................................................................................................................1
1.2. Existing system study...........................................................................................................................2
1.3. Statement of the problem....................................................................................................................2
1.4. Objective of the project.......................................................................................................................2
1.4.1. General Objective of the project.................................................................................................2
1.4.2. Specific Objective of the project.................................................................................................3
1.5. Scope of our proposed system.............................................................................................................3
1.6. Significance of the project...................................................................................................................3
1.7. System requirement.............................................................................................................................4
1.7.1. Hardware requirement................................................................................................................4
1.7.2. Software requirement..................................................................................................................4
1.8. Methodology.........................................................................................................................................5
1.8.1. Data gathering methodology.......................................................................................................6
1.8.2. Design methodology.....................................................................................................................6
1.8.3. Implementation methodology......................................................................................................6
1.8.4. Testing Methodology....................................................................................................................7
1.9. Feasibility studies.................................................................................................................................7
1.9.1. Technical feasibility.....................................................................................................................7
1.9.2. Operational feasibility.................................................................................................................7
v
 1.9.3. Economic feasibility.....................................................................................................................8
1.9.4. Schedule feasibility of the project (using Gantt chart)..............................................................8
1.10. Cost Analysis....................................................................................................................................9
CHAPTER TWO...........................................................................................................................................10
2. System Analysis......................................................................................................................................10
2.1. Overview of the existing system....................................................................................................10
2.2. System requirement...........................................................................................................................11
2.2.1. Functional requirement.............................................................................................................11
2.2.2. Non-functional requirement......................................................................................................12
2.3. Overview of Proposed System...........................................................................................................13
2.4. Business Rule......................................................................................................................................13
2.5. System Requirement Analysis...........................................................................................................14
2.6. Actor and Use Case Identification....................................................................................................14
2.7. Use case Diagram...............................................................................................................................17
2.8. Use case description...........................................................................................................................18
2.9. Sequence diagram...............................................................................................................................22
.................................................................................................................................................................24
.................................................................................................................................................................27
2.10. Activity diagram.............................................................................................................................29
.................................................................................................................................................................29
.................................................................................................................................................................30
2.11. Class diagram...................................................................................................................................32
Chapter Three................................................................................................................................................33
3. SYSTEM DESIGN...................................................................................................................................33
a. Design Class diagram............................................................................................................................33
b. System decomposition............................................................................................................................34
c. System architecture...........................................................................................................................35
System architecture diagram.............................................................................................................37
d. Deployment diagrams........................................................................................................................37
f. User interface design...........................................................................................................................39
g. Development Methodology.................................................................................................................41
h. Development Approach.......................................................................................................................41
vi
 i. Database design /Physical data model.................................................................................................42
CHAPTER 4: Implementation.......................................................................................................................43
Overview of Programming Language...........................................................................................................43
4.2 Algorithms Used...............................................................................................................................43
4.2.1 Algorithm for Login..................................................................................................................43
4.2.2 Algorithm for Forgot password................................................................................................43
4.3 Pseudo code.................................................................................................................................44
A. Sample Code for Admin login...........................................................................................................44
B. Sample Code for Home....................................................................................................................47
CHAPTER 5: Testing..........................................................................................................................................49
5.1 Unit testing......................................................................................................................................49
5.2 Integration testing...........................................................................................................................49
5.3 System testing..................................................................................................................................49
5.4 Acceptance testing...........................................................................................................................49
CHAPTER 6. Conclusion and Recommendations...........................................................................................50
6.1. Conclusion.............................................................................................................................................50
6.2.1 Recommendation.....................................................................................................................50
6.2.2 Feature enhancement..............................................................................................................50
Reference.........................................................................................................................................................51

vii
List of Figures
Figure 1:Use case diagrams.............................................................................................................................17
Figure 2:UML sequence diagram for login.......................................................................................................23
Figure 3:UML sequence diagram for bill calculates.........................................................................................24
Figure 4:UML Sequence diagram for order maintenance................................................................................25
Figure 5:UML sequence diagram for registration............................................................................................26
Figure 6:UML sequence diagram for create account.......................................................................................27
Figure 7:UML Sequence diagram for view order or request............................................................................28
Figure 8:Activity diagram for login...................................................................................................................29
Figure 9:Activity diagram for bill calculating....................................................................................................30
Figure 10:Activity diagram for apply registration.............................................................................................30
Figure 11: Activity diagram for order maintenance.........................................................................................31
Figure 12: Activity diagram for customer expert diagram...............................................................................31
Figure 13: Activity diagram for post vacancy diagram.....................................................................................31
Figure 14: Class diagram..................................................................................................................................32
Figure 15: design Class diagram.......................................................................................................................34
Figure 16: system decomposition....................................................................................................................35
Figure 17: System architecture diagram..........................................................................................................36
Figure 18: Deployment Diagram......................................................................................................................37
Figure 19: design class diagram.......................................................................................................................38
Figure 20: Homage user interface....................................................................................................................39
Figure 21: User interface for apply registration...............................................................................................40
Figure 22: User interface for login...................................................................................................................41
Figure 23: Database Design.............................................................................................................................42

viii
List of Tables
Table 1: Front and back end design tools..........................................................................................................5
Table 2: Schedule feasibility..............................................................................................................................8
Table 3:shows the cost of the proposed system................................................................................................9
Table 4:use case identification.........................................................................................................................16
Table 5:use case login......................................................................................................................................18
Table 6: Apply register....................................................................................................................................19
Table 7: Customer order service......................................................................................................................20
Table 8: Table 8:View report............................................................................................................................21

ix
CHAPTER ONE:

1. INTRODUCTION
Technology is spreading its wing in almost every walks of human life activities. Now days it is
better if every activity is done using new technology in order to fulfill the need of human being,
Organization and Enterprise etc. As today’s world there are many organizations and each
organizations needs to be preferable, computable and work on fastest way in order to satisfy users
interest etc. i.e. they should have facilitated their activities in computerized way.
Water supply management system is powerful, flexible easy to use and designed to deliver real
conceivable benefits to office. The organization would help to solve the problems by replacing the
way of desktop application into computerized system. When we see how the new customer joins the
organization, it requires physical present to the office. So, the project tries 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.

1.1. Background
The importance of computer cannot be over emphasized since the ancient times, computer has
proven itself capable of accepting data, storing, processing and producing an accurate result or
output. Since computer has partially taken most of the responsibilities of human being, i intend to
embed the use of computer in the billing exercise.

Debre Markos water and sewerage service (DMWSS) is a water supply organization which is in
Debre Markos city. The organization is established in 1945 E.C as part of the city administration,
with the name called “Water section”. At that time, the office had only five employees’ water
chemist, motor operator, meter reading expert and two security bodies. DMWSS follows semi
automated system to give service for their customer. Until 1971 E.C the office had only around 800
customers, which register to apply the service. But, in 1971 this “Water section” builds its own
office and become independent organizational office by the name called DMWSS, within
13employees under the workplace. Currently, the organization has many customers and employees.

1
the organization the past 2012E.C 17,059 customers and has 150 employees which they register
under this office

1.2. Existing system study

The existing system is practice at Debre Markos water and sewerage service and the system uses
desktop application. New customer registers to the system first on paper by giving full information
to get water service from system, later on the customer’s register on the computer during this time
interval the customer’s information may be lost and difficult for getting feedback on the right time.
The main purpose of studying the existing system is to understand the existing system problems and
develop a new system which solves the above problem

1.3. Statement of the problem

Debre Markos water and sewerage service is currently uses desktop application systems. As it is
desktop application, they have their own problem like:
 Waste of time and cost by customer to get the service in the existing system since the
customer must physically present to get the service.
 The customer’s data may be lost since initially the customers information register on
paper and requires more labor force to record their data manually.
 Increase of work load on the employer of the organization since every activity can be
done manually.
 Lack of data integrity and leads to information redundancy.
 Bulky and ambiguous to retrieve information.
 The existing system time taken and tedious to generate a report due to the file
handling approach manual

1.4. Objective of the project

1.4.1. General Objective of the project

The main objective of the proposed system are to design a web based water supply office customer
service management system in Debre Markos City which solves the above mentioned problems with
the existing system.

2
 1.4.2. Specific Objective of the project

Specific objectives are required to complete general objective. Here are some specific objectives:

 To gather and analysis the problem statements in existing system

 To design a user-friendly system that allows a customer view the bill they
should paid.
 To design a well-organized data base that allow handle customer details
 To study and identify the problem under the existing system.
 To implement and test the system.
 To add new customer and develop a database that hold customer information.
 To receive meter value or monthly customers water consumption and calculate bill.
 To generate bill and post for the customer.
 To receive customer maintenance order from the customer.

1.5. Scope of our proposed system

Scope
The proposed system on developing web based Debre Markos water and sewerage service for Debre
Markos city.
Some of the functionality of the proposed system we will initiate to do is:-
 Record new customer if not present
 Search the document of existing customer
 Reporting customer information to the system manager
 Generate bills for customer for the services they get
 List and notify set of appointments for their maintenance order
 Notify customers at the end of month to read the water meter.
 Managed the systems data.

1.6. Significance of the project

 Our proposed system provides the following significance:
 The system will save the customer’s time and cost when they want to access service from the
organization, the customers uses the system safely and gives comfort for them.
 The system motivates many customers to join the system, as it is easily accessible.
3
  It increases performance of the organization since every activity can be done in the fraction
of second within out any difficulty.
 The system makes the office more efficient and profitable in a short period of time.
 Reduce man power and work load of the organization.
 To minimize cost of copying or duplicating materials
 It will provide updated information to billing systems such as announcing the
registration date, new information and etc.
 It provides extra knowledge of using computer to customer.
Limitation of the project

 The project does not work about employee salary or pay rolling and detail information
about employee.
 Our project is language dependent doesn’t support another language except English
Language.
 The proposed system doesn’t support offline connection.

1.7. System requirement

1.7.1. Hardware requirement

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.
External hard disk, Disks (CD, DVD): necessary for the movement of relevant data and for backup
and recovery mechanism.
Network cable: It helps us to extract relevant information about our project from internet.

1.7.2. Software requirement

 For design interface.
 For create database.
 For write and run our code program efficiently and effectively.
 XAMPP and Wamp Server
 Rational Rose, Visual Paradigm,- For designing E draw UML diagrams associated with `the
project.
 Microsoft office 2010: - for documenting the corresponding deliverables associated with the
4
 project.
 Back end design tool
 MYSQL software of the data base system and PHP language is used in developing and
managing the back end of the system.
 Front end design
 The user interface had been developed using HTML, java script and CSS since it is easily
designing the front end and connected into database easily.
 Generally, use notepad++ : - for writing code.

Activity Tools/programs

Client side coding HTML

Clint side script Java script
Database server PHP
Design tools E-draw max
Documentation MS word

Table 1: Front and back end design tools

1.8. Methodology

The team chooses object oriented analysis and design approach to analyze and design the system,
based on our preliminary analysis of the old system.

In our project the team will use Object Oriented Software Development Methodology (OOSD)
because it has the following advantages: -
 Increase reusability: - the object oriented provides opportunities for reuse through the
concepts of inheritance, polymorphism, encapsulation and modularity.
 Increased extensibility: - when there is a need to add new feature to the system you only need
to make changes.
 Improved quality: - quality of our system must be on time and meet our exceeded the
expectation of the users of our system, improved quality comes from increased participation
of users in the system development.

5
 1.8.1. Data gathering methodology

We use document analysis in order to obtain the information about the practices and problems of the
water supply office customer service management system which ultimately assists us in developing
the computerized system. There are saved documents referred for the preparation of the system. In
addition, we use internet access.

Document analysis: The team reviewed documents such as books, e-books and some related
previously done projects which are very important to develop our project. During the analysis of
documents, we give a special consideration to those documents which can bring more features to our
system.
Interview: This is one of data collection method that enables to gather information from the
organization directly in the form of asking question and getting answers for those questions. So, we
will use this method to gather information by asking the manager of the water supply office
customer service management system some basic questions regarding the following issues will be
asked during the interview:-
 How water supply management system is going on?
 During managing, are there any problems? If there, what are they?
 What requirements are needed for the process?
 Who is responsible for what?
Observation: This is also another data collecting method. In fact we have also used this observation
method to gather data. This method enables us observing and understanding how water supply
customer service management system information management is going on.

1.8.2. Design methodology

To design the system we used object-oriented methodology instead of structured approach, since it is
more acceptable due to its great advantage of modularity, inheritance, and persistence.
Reason of choosing:
Modification of the object implementation is easy because object is loosely coupled. Understanding
of the structure is easy because object oriented modeling and tools used to represent real world
entities.

1.8.3. Implementation methodology

For the new system to be efficient there is a requirement for specific hardware and software.
6
 1.8.4. Testing Methodology
After a successful completion of developing the software, we must test it for its correct functionality
according to customer requirement and scope boundaries. A testing method that we use in this
project includes:
 Unit testing: We select sample code (one function or module) and run it separately to look
its correct functionality.
 Integration testing: When a number of components are complete; it will test to ensure that
they integrate well with each other the operating system and other components.
 Acceptance testing: This testing is done by the customer (on-behalf) to ensure that the
delivered product meets the requirements and works as the customer expected. It includes:-
 Alpha: - As the team we test our implemented code before releasing to the market by using
two phases.
 First phase that we follow as the developer we debug by using our wamp-server and
different browser.
 In the second phase we follow the methods QA staff for additional testing.
 Beta:- We conducted some users to ensure whether or not accept our implemented system.

1.9. Feasibility studies

1.9.1. Technical feasibility

Technical feasibility deals with the hardware as well as software requirements .We have to find out
whether the necessary technology and proposed equipment have the capacity to hold the data used
in the project. The system will be developed using the object oriented development
technique ,since the team member have the knowledge of the methodologies and the tools to
develop this system (for data gathering, implementing or coding developing the program ) the
project is to be technically feasible.

1.9.2. 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 intern increases the efficiency of work in the office. So that one can say that the system is
operationally feasible.

7
 1.9.3. Economic feasibility
Economic feasibility is the process of identifying the financial benefits and costs associated with the
project being developed. It is a measure of cost effectiveness of a project and also used to identify
the benefits and costs concerning the project. Under economic feasibility we consider the following
things.
Intangible benefits: refers to items that cannot be measured in terms of money.
The following Intangible benefits are as follow:
 Minimizing the work load of the employee.
 Give moral satisfaction for the user of the system.
 Tangible benefit: is a benefit that can easily be measurable. Our system will provide tangible
benefits such as:
 Increase speed of activity for the organization employee.
 Decrease labor force.
 Decrease response time for the requested information within maximum fraction of second.

1.9.4. Schedule feasibility of the project (using Gantt chart)

No. Task January February March April June

1 Requirement
Analysis

Object design document

2
System design document

3
4 Implementation

5 Tasting and maintenance

Table 2: Schedule feasibility

8
 1.10. Cost Analysis

To complete our project starting down from the beginning up to the end of this project we planned
the following cost list.

No Item quantity Price per item Total price

1 Paper 120 0.50c 60

2 CD 3 25 75
3 Pen 3 10 30
4 Mobile card 5 25 125
5 Print 80 1 80
6 Binding 2 10 20
7 Miscellaneous cost - - 550
8 Flash 1 150 150
9 Pc 1 12,500 12,500
Total 9 210 13,590
Table 3:shows the cost of the proposed system

9
CHAPTER TWO

2. System Analysis

2.1. Overview of the existing system

The existing system is operating in semi-manually. Different activities which are

performed in existing systems are Customers are registered manually when they want to
get the service, Customer report different request like maintenance to the organization
manually, Meter reader moves every customers house to read the meter, Customer do not
know the amount of money the they pay before they are informed, Backup data was
stored in manually by using cabinet and suspension card, The billing system was done
from the hierarchy of meter reading to bill officer, then bill officer to accountant and
from accountant to bill collector and vice versa, The organization makes a general report
about the billing system once at the end of the month and generates the report. And also,
Customers inform physically to their technical supervisor when service maintenance was
needed.

Users of the existing systems are

Customer: peoples of Debre Markos town who get service form Debre Markos water
and sewerage organization.

Bill reader: an employee whose responsibilities are went to site in order to read the
water meter per a month and report the result to the bill officer.

Bill officer: An employee who works on the billing system office and have the
responsibilities of to approve new customer application, takes the customer’s monthly
reading value from the bill reader calculate the value of each customer using the system
and transfer each result to the accountant and bill collector and also She/he responsible to
generate the report that reads by the bill collector using the system.

Accountant: A professional person who performs accounting functions such as audits or

financial statement analysis, which responsible to takes the final value from the Bill

10
officer and asks the customer to pay their fee depend on the calculated value. After the
payment the Accountant must be transfer the overall deposit of the customer to the Bill
collector.
Bill calculation: Backup data was stored in manually by using cabinet and suspension card and
also CD, hard disk device. Customer must inform the office if his/her reading value was not done in
timely manner by being physically available at the office

Technical supervisor: An employee who works on the maintenance service of

customers, they have activities like receives the maintenance order of the customers and
he performs the activity based on the given order.
Report generate: The organization makes a general report about the billing system once at the end
of the month.

2.2. System requirement

System Requirement Specification is official statement of what the system developer should
Implements or behavior of system to be developed. SRS fully describes what the software will do
and how it will be expected to perform

2.2.1. Functional requirement

A functional requirement describes what a proposed water supply management

system should do.

Some of the functionalities of the proposed system are: -

 Create account.

 New customer registration.

 Delete account/ comment/ Delete meter reading.
 Update account/ update meter reading.
 Record meter reading, record meter activity.
 Bill generates and prints.
 Receive customer services order from manager.
 Update customer.
 View report.
11
  Order maintenance service and give feedback for the customer.
 Give privilege for all users.

2.2.2. Non-functional requirement

Non-functional requirements are the ones that relate with the reliability of the system. These
requirements indirectly affect the performance of the system. They are used to build quality of the
system. The following are the non-functional requirements for the new system.
 Error handling: -The system handles errors by giving error-message.
 Availability: -the developed system is available at any time in the customer service.
The system shall have high availability.
 Usability: -Since the system is easily accessed it is easily used everywhere in which
internet connection is available.
 Performance: -The system should have a quick response time for a single request
made. It is expected that the software would perform functionally all the
requirements that are specified by the organization.

 Portability: A language is said to be portable, if its source code is compiled

(accessed) by any computer system, regardless of the operating system on which the
user is compelling. Thus, having this in mind, our system is portable at all, because
we have implemented, the project using an object-oriented language.
 Storage capability: The system has an ability to store the required information of the
customer in the database

12
 2.3. Overview of Proposed System

Proposed system means explaining what we are going to do this project. What is our
project and what is new in our project other than existing things? And how we are
going to do this.

The proposed system aims to be better understanding consumption pattern of the customer
and extracting water meter reading data with less human interaction in efficient manner.so,
web based water supply customer service management system is a system which is used to
help both customers of the system and organizations to facilitate their works. Mainly
focuses on solving the problem of managing customer file and workload, water meter
reading, billing. It reduces the time and task required to perform the operation within the
organization.

2.4. Business Rule

A business rule is effectively an operating principle or policy the software must satisfy. It often
relevant to access control issues, business calculations, or operating policies and principles of the
organization. Therefore, our new system has the following business rules.

BR1: Customer must be registered and get permission from service provider to get service.

BR2: Bill officer must read water meter result and send it to the system to know the amount of
money they will pay.

BR3: Manager must view register customers, view payment and report.

BR4: Technician must perform the activity as the provided order and Receive customer services
order from manager

BR5: Customer service expert view customer information and update customer information

BR6: The user should have a system to get the service.

BR7: Administrator has the privilege of managing the overall activities of the user account

13
BR8: The user must have an account to get a service.

BR9: The customer must pay two times of a month if he or she pay the bill on time

2.5. System Requirement Analysis

System requirement analysis is an integral part of information systems design and is critical to
the success of interactive systems.

2.6. Actor and Use Case Identification

Actors: An actor represents a type of users of the system that the system interacts
with. The purpose of actor analysis is to identify all of the actors that interact with the
system. An actor is a user of the system playing a particular role. The actors that
interact with the new system are:
Customer: Is the actor who is act into the system to get service.
 Apply registration.
 Order or request maintenance service.
 View his own report.
 Pay bill
Administrator: Is the actor that has the privilege of managing the overall activities of the user
account such as.
 create account
 delete account/update account
 delete comment
 Delete vacancy/update vacancy/ post vacancy

14
Manager: Manager be able to:-
 view an activity
 view information
 view the payment
 View prepared bill.
Customer service expert: Customer service expert be able to:-
 delete customer,
 update customer
 view information
 View payment.
Technician supervisor: An employee who controls mainly the overall maintenance service of
customers, specifically he has the following activities.
 Receive customer services order from manager
 Sent services delivery report to manager
 View information posted by manager
Bill officer: - is an employee, who works on customer service office, which have the following
responsibilities.
 record meter reading
 bill generate and print
 record meter activity
 Delete meter reading/ update meter reading

Use Case ID Use Case Name Include

15
 UC01 Login
UC02 Manage User Account UC01
UC03 View Information UC01
UC04 Update information UC01
UC05 Register customer UC01
UC06 Read water meter UC01
UC07 View bill history UC01
UC08 View current bill UC01
UC09 Make payment UC01
UC10 Send maintenance request UC01
UC11 Generate report UC01
UC12 post vacancy UC01
UC13 Update vacancy UC01
UC14 View vacancy UC01
UC15 View Report UC01
UC16 Create Backup UC01
UC17 Send Request UC01
UC18 View Request UC01
UC19 Update Request UC01
UC20 Report for performed maintenance UC01
UC21 Recovery UC01
UC22 Monitor System security UC01
Table 4:use case identification

2.7. Use case Diagram

Use cases: A use case describes the sequence of events of some types of users, called Actors,
using some part of the system functionality to complete a process.

16
A use case diagram is a graphic depiction of the interactions among the elements of a system.
Use case diagram shows use cases, actors, and their interrelationships. A use case is a
methodology used in system analysis to identify, clarify, and organize system requirements

Figure 1:Use case diagrams

17
 2.8. Use case description

Use case description is documents that contain brief information about use case. use
case description contain the components like use case name, use case ID, participate
actor, description, basic course of action, alternative course of action, pre-condition
and post-condition.

Table 5:use case login

Use case name Login

Use case Id UC01
Actor Manager, Customer expert service, Customer, Technician supervisor,
Administrator ,Bill officer
Description To login into the system by their user name and password.
Pre-condition Manager, customer expert service, Customer, Technician supervisor,
Administrator and Bill officer must have user account
Post condition Manager, Customer expert service, Customer, Technician supervisor,
Administrator and Bill officer can access the authorized system.
Basic courseof Actor Action System Response
action
Step1: users open the system Step2: The System displays login

Step3: User enters username and password, form.

then after click login button.
Step4: The system
verifies username and
password

Step5: user went into

the specified systems
interface.
Step6: The use case ends.
Alternative If the user enters wrong user name and/or password, the system displays incorrect
curse of action user name and/or password message and use case continues step 3.

18
Use case name Apply registration

Use case number UC02

Description The customer request the service by using web based application
of DMWSSO

Actor Customer

Pre-condition The customer must have internet connection.

Basic course of action (Flow 1 The customer wants to register by selecting register link.
of event)
2 The system displays the register form page.

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

4 The customer click submit button. (Alternate 4).

5 The system displays the id no and information’s of the

customer.

6 The use case ends.

Post-condition The customers join to the organization and get the service.

Table 6: Apply register

19
Use case name Order maintenance service

Use case number UC03

Description The customer enables to select the technical link and fill the
request.

Actor Customer

Pre-condition Must have user name and password.

Basic course of action (Flow 1 The customers want to fill the request by selecting technical
of event): link.

2. The system displays the technical form page.

3. The customer fills the inputs his/her required information.

4. The customer click save button (Alternate 4).

5. The system displays the customer’s request information.

6. The use case ends.

Post-condition Maintenance order record to the system.

Alternate course of action The filled register information is invalid. Then Go to 3.

Table 7: Customer order service

20
Use case name View report

Use case number UC04

Description Some actors are view report.

Actor Customer service expert, Manager, customer

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

Basic course of action or 1. The actor selects view report link.

Flow of event
2. The system displays the view report page.

3. The customer press alternative view icon.

4. The system displays their data to customer service expert from

DMWSCSO database.

6. The use case ends

Post-condition The report is viewed by the users.

Table 8: Table 8:View report

21
 2.9. Sequence diagram
A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the
instances participating in the interaction by their “lifelines” and the stimuli that they arranged in
time sequence. It does not show the associations among the objects.

Sequence diagrams are used to model the logic of usage scenarios or the description of the
potential way the system used. Sequence diagrams are a great way to validate and flesh out the
logic of use case scenarios and to document design of the system.

22
 Figure 2:UML sequence diagram for login

Figure 3: UML sequence diagram for bill calculates.

23
Figure 4:UML Sequence diagram for order maintenance

24
Figure 5:UML sequence diagram for registration

25
Figure 6:UML sequence diagram for create account

26
Figure 7:UML Sequence diagram for view order or request

27
 2.10. Activity diagram

An activity diagram is a variation of a state machine in which the states represent the
performance of actions or sub activities and the transitions are triggered by the completion of the
actions or sub activities. It represents a state machine of a procedure itself. Activity diagrams
model is a high level business or processes or transitions between states of a class. In this activity
diagram we tried to document the flow of logic for the major business processes of this project.
The activity diagram below shows the users activity performed on the water billing management
system for Debre Markos water and sewerage service.

Figure 8:Activity diagram for login.

28
 Figure 9:Activity diagram for bill calculating

Figure 10:Activity diagram

for apply registration.

Figure 11: Activity diagram for order maintenance

29
Figure 12: Activity diagram for customer expert diagram

Figure 13: Activity diagram for post vacancy diagram.

30
 2.11. Class diagram
Class diagrams in the Unified Modeling Language is a type of static structure diagram that
describes the structure of a system by showing the system's classes, their attributes, operations
and the relationships among the classes. The class diagram with its corresponding objects will be
present in the following diagram.

Figure 14: Class diagram

31
Chapter Three

3. SYSTEM DESIGN
3..1 Design Goal
The design goals are derived from the non-functional requirements of the system, which were
stated in the above chapter of this document. They describe the qualities of the system. These
goals consider the following designing considerations. Some of the design goals are:-
 Availability: the developed system is available at any time which menaces that system
needs to be on work for 24 hours in a day and 7 days in a week.
 Usability: The system should have user friendly user interface to allow the user to
interact with the system easily.
 Performance: The main performance of the system is response time, so the system can
give fast response for a user request.
 Portability: -The system should be well suited to work on any machine running windows
operating system.
 Security: system provides security controls through authentication, authorization and
data protection. The authentication is by confirming a user. The authorization is by
verifying the authenticated user has permission to access a particular resource.
 Fault tolerance (error handling): The system should be able to give response (Error
Message) when someone tries to enter incorrect input. This recommends the user to enter
correct input.
 Supportability: the system can support many customers at a time where internet
connection is available.

a. Design Class diagram

Class diagrams in the Unified Modeling Language is a type of static structure diagram that
describes the structure of a system by showing the system's classes, their attributes, operations
and the relationships among the classes. The class diagram with its corresponding objects will be
present in the following diagram.

32
 Figure 15: design Class diagram

b. System decomposition
Any system can be decomposed in to different sub system based on the functional services. A
subsystem is characterized by the services it provides to other sub system. Services are a set of
related operations that has a common purpose. In order to make the implementation easy and
manageable, the newly developed system decomposed in to the smaller subsystems.

33
Our system has the following sub system

 Administrator subsystem

 Customer’s subsystem

 Meter reader sub system

 Bill officer subsystem

 Technician subsystem

34
 Figure 16: system decomposition

c. System architecture
The system architecture diagram shows the connection between different machines and the
path they are connected to each other. The proposed web application architecture consists of
a client at the end user side, and a 3-tier processing in server side (presentation tier, business
tier and back-office tier.
 Client tier- The client tier consists of computers which have one or more web
browsers installed on it. The end user will use the browser to communicate to web
server using some protocols like HTTP or HTTPS.
 Presentation tier- The presentation tier is an agent to communicate client with
application server. And it is responsible for transfer request of the client (end user) to
application server and also transfers response to the client.
 Business tier- The business tier contains the application server. The application
server implements the actual business rule and organizational units. It will interact
with Back-office tier if user request need database access or if user needs to store or
retrieve data to/from database.
 Back-office tier- The back-office tier provides some basic services to the business
tier, such as a database system and an authentication or acknowledge and directory
service.

35
 Figure 17: System architecture diagram

System architecture diagram

d. Deployment diagrams
Deployment diagrams are used for describing the hardware components where software
components are deployed. It focuses on hardware topology of a system. Deployment diagram
have several valuable applications:
 Show which software elements are deployed by which hardware elements.
 Illustrate the runtime processing for hardware.
 Provide a view of the hardware system’s topology

36
 Figure 18: Deployment Diagram

e. Persistent data management

Persistent data management deals with how the persistent data (file, database, etc) are stored,
managed and it outlive a single execution of the system. Information related to programs basic
information, and the schedule timetable produced and other related information are persistent
data and hence stored on a database management system. Moreover, storing data in a database
enables the system to perform complex queries on a large data set. For complex queries over
attributes and large data set Microsoft SQL Server is implemented, which is a Relational
Database Management System.

37
 Figure 19: design class diagram

f. User interface design

User interface design is the overall process of designing how a user will be able to interact with a
system. The system uses user interface design to make the user's interaction as simple and
efficient as possible, in terms of accomplishing user goals.

38
 Figure 20: Homage user interface

39
Figure 21: User interface for apply registration

40
 Figure 22: User interface for login

g. Development Methodology
Among the different development methodologies available, the project team choose object-
oriented methodologies for the analysis and design of the system. Object oriented methodology
enables to represent complex relations among different objects and represent data and process
with consistent notation throughout the system. An important feature such as inheritance,
polymorphism, data hiding and encapsulation suits the design very well and simple, modifiable,
maintainable and reusable so, the whole system analysis, system design and implementation
taken using object-oriented methodology.

h. Development Approach
To develop the project, the teams chosen iterative model. The purpose of working iteratively is
to allow more flexibility for changes (O. a. Victor, 2017).

Advantages of this model are:

 It easily adaptable to the ever-changing needs of the project as well as the patient.
 It can be more cost effective to change the scope or requirements in Iterative model
 To testing and debugging during smaller iteration is easy.

41
  Risks are identifying and resolve during iteration; and each iteration is an easily
managed.

i. Database design /Physical data model

Physical database design translates the logical data model into a set of SQL statements that
define the database. For relational database systems, it is relatively easy to translate from a
logical data model into a physical database. The physical design of the database optimizes
performance while ensuring data integrity by avoiding unnecessary data redundancies. During
physical design, you transform the entities into tables, the instances into rows, and the attributes
into columns. Rules for translation from logical to physical database design:

 Entities become tables in the physical database.

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

Figure 23: Database Design

42
CHAPTER 4: Implementation
Overview of Programming Language
The system implemented by Phased Adoption. Phased Adoption means that the adoption happens in
several phases, so after each phase the system is a little closer to be fully adopted by the organization. It
used for the existing system remove step by step. Phased adoption implementation is better than the direct
and the parallel implementation according with the project team select for system were develop because it
gives great advantage than direct implementation, when the system damaged and cost effective than
parallel implementation. Therefore, the project team chosen Phased Adoption implementation. Also
system implement using different software applications, hardware applications and different languages.
The system can be implement using different languages example: PHP, CSS and MYSQL.

4.2 Algorithms Used

4.2.1 Algorithm for Login
Start Page
Click on login link
Login form displayed
Enter
Username and password
Click login button
Connect to database
If (valid)
The privileged page displayed
Else
Display error message /return value

4.2.2 Algorithm for Forgot password

Login Page
Click on forget password link
Forgot password form is displayed
Fill email and mobile number
Enter new password and confirm password
Click on forget password button

43
Connect to database
If (valid)
Display successful message.
Else display invalid input message

4.3 Pseudo code

Pseudo code is a detailed readable description of what a computer program or algorithm must do,
expressed in a formally-styled natural language rather than in a programming language. Pseudo
code is sometimes used as a detailed step in the process of developing a program. It allows
designers or lead programmers to express the design in great detail and provides programmers a
detailed template for the next step of writing code in a specific programming language. The
purpose of using pseudo code is that it is easier for people to understand than conventional
programming language code, and that it is an efficient and environment-independent description
of the key principles of an algorithm

A. Sample Code for Admin login

<html>
<head>
<style type="text/css">

form {
background: -webkit-gradient(linear, bottom, left 175px, from(#CCCCCC),
to(#EEEEEE));
background: -moz-linear-gradient(bottom, #CCCCCC, #EEEEEE 175px);
margin:auto;
position:relative;
width:370px;
height:250px;
font-family: ;
font-size: 14px;
font-style: italic;
line-height: 24px;
font-weight: ;
color: #09C;
text-decoration: none;
-webkit-border-radius: 10px;

44
-moz-border-radius: 10px;
border-radius: 10px;
padding:10px;
border: 1px solid #99779;
border: inset 0px solid #333;
-webkit-box-shadow: 0px 0px 8px rgba(0, 0, 0, 0.3);
-moz-box-shadow: 0px 0px 8px rgba(0, 0, 0, 0.3);
box-shadow: 0px 0px 8px rgba(0, 0, 0, 0.3);
}
.style1 {
color:#000033;
font-weight: bold;
}
.style2 {color: #0000FF}
body {
background-image: url(Image/main.jpg);
}
.a input[type="submit"]{
width:65px;
height:25px;
border:1;
border-radius:5px;
border-bottom-style:solid;
border-color:#00CC33;
-webkit-border-radius:5px;
background-color:#99FF00;
}
.a input[type="reset"]{
width:65px;
height:25px;
border:1;
border-radius:5px;
border-bottom-style:solid;
border-color:#00CC33;
-webkit-border-radius:5px;
background-color:#99FF00;
}

45
.a input[type="text"]{
width:150px;
height:30px;
border:1;
border-bottom-style:solid;
border-color:red;
border-radius:5px;
-webkit-border-radius:5px;
}
.a input[type="password"]{
width:150px;
height:30px;
border:1;
border-bottom-style:solid;
border-color:red;
border-radius:5px;
-webkit-border-radius:5px;
}
</style>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head>
<body ><p align="center">

<table width="463" border="0" class="a">

<tr>
<td width="64" height="221">&nbsp;</td>
<td width="389">
<form action="form1/adminlogincode.php" onsubmit='return formValidator()'
method='POST' target="_top" id='form1'>
<h2 align='center' class="style1">Adminsitrator login form</h2>         
<div align="center"><span class="style2"></span>
<font color="#000033" size="+1">User
Name</font>&nbsp;&nbsp;&nbsp;&nbsp;<input type="text" name="user_name"
id="user_name" placeholder="Insert User Name" id="username">
<br>
<br>
<span class="style2"></span>

46
 <font color="#000033"
size="+1">Password</font>&nbsp;&nbsp;&nbsp;&nbsp;<input type="password"
name="password" id="password" placeholder="Insert your password"><br /><br />

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<input type='submit' name="submit"
value="Login" />&nbsp;&nbsp;
<input type='reset' value='Reset' />
</div>
</form></td>
</tr>
</table>
</p>
</body></html>
B. Sample Code for Home
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled Document</title>
<style type="text/css">
body {
background-color:
font-family: Georgia, "Times New Roman", Times, serif;
font-size:20px;
line-height: 20px;
color: #336699;
background-image: url();
}</style>
</head>

47
<table width="610" height="517" style="text-shadow:0px 0px 1px black;box-
shadow:rgba(0,0,0,0.3) 0px 0px 1px;" >
<tr><td width="8" height="179" bgcolor="" style="font-style:italic;"><h4><font
color="black">
</font></h4></td>
<td width="491" bgcolor=""><p><font color="black"> This Customer Management System is
a comprehensive web-based Customer service Management
Software. It is designed for better interaction between Customer,Bill officer,
Technical supervisor, Customer service exprt and Manager management. This management
software very gracefully handles all
the requirements for easy Customer Management.
The software being web based can be accessed from any where in the world which
enables the Customer ,Bill officer ,Technical supervisor and Managerthe management be in
touch with each
other at all times.<br />
<h> </h>
To access this system you have to login based on your privillage
just by selecting from options provided below. </font></p>
</td>
<td width="138" bgcolor=""><img src="Image/64.jpg" width="172" height="297" /></td>
</tr>
<tr>
<td height="26" colspan="3" align="left" style=" background-image:url(image/gold.jpg"><font
color="#000066"> &nbsp;&nbsp;&nbsp;&nbsp;Login As </font> &nbsp;
<select id="mySelect" onChange="if(this.options[this.selectedIndex].value != '')
{frame.location.href=this.options[this.selectedIndex].value}">
<option value="adminlogin.php">Adiministrator</option>
<option value="billofficerlogin.php">Bill officer</option>
<option value="Technicallogin.php">Technical supervisor</option>
<option value="customerexpertlogin.php">Customer service expert</option>

48
 <option value="manager.php">Manager</option>
<option value="MeterRreaderlogin.php">Meter Reader</option>
</select></tr>
<tr>
<td align="center" height="302" colspan="3"><iframe src="adminlogin.php"name="frame"
frameborder="0" width="600" marginwidth="" height="450" align="center" marginheight=""
scrolling="auto"></iframe></td>
</tr></table>
</body>
</html>

CHAPTER 5: Testing
Testing is a process to show the correctness of the program and design to analyze the logics use
in the implementations of the System. It also checking of the system works ability in an attempt
to discover errors and avoiding such errors from the system.

5.1 Unit testing

Unit testing is a system verification and validation method in which a programmer tests if
individual units of source code are fit for use. The system units tested one by one each unit. It
can do the tests as follow in unit testing:

5.2 Integration testing

Combining modules and testing them is called integration testing. Integration testing is gradual
process. First we tested the highest level, or coordinating module, and only one of its
subordinate modules. After unit testing, the web-based water supply management system is also
test whether every unit can be integrating to each other. Therefore, the system used Integration
testing to integrate modules.

5.3 System testing

It is the final step of testing. In this the project 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 project teams tests all the functionalities in the System. All errors in the forms,
functions, modules are tested.

5.4 Acceptance testing

Acceptance testing is the process of testing system prior to its delivery. A system mainly
developed for an end user normally a customer of the organization. A system is said to be

49
accepted if and only if the user of the system is satisfied. In this perspective acceptance, testing is
widely use to prove that system performs as per the requirements. In acceptance, testing the user
could be provided the input data to validate the system operation.

CHAPTER 6. Conclusion and Recommendations

6.1. Conclusion
When we come to the conclusion of our project, Debre Markos water supply is used manual system for
start up to know so we motivated to change in to computer based so we develop web based Debre
markos water supply system for debre markos water supply by using different methodology in order to
build the system. generally, the system we build perform the work flow the organization.

So our team develops this system to solve the above problems during the period of development there
was some challenges we faced. By passing various challenges, now the team is coming to the end of this
and it can solve the problems of current manual system.

6.2 Recommendation and Future Enhancement

6.2.1 Recommendation

The team would like strongly recommend web based debre markos water supply management system
very good for the supply it minimize most of the manual aspect of work so we recommend that if the use
the system the make their organization profitable. Additionally, the teams recommend the other
developers to do the employee salary and other internal water supply activity then system can provide
better service for the organization.

6.2.2 Feature enhancement

Due to time limitation we can’t do all the tasks that are needed in the system, so to enhance the
performance and functionality of the system the next developer can include the following tasks.

Fully automate the system by including online payment system.

Make the system fully accessible in Amharic language.

Develop better security mechanism than the current security like two step verification.

Reference
1. Industrial Project I Final-signed DTU.pdf

50
2. http://196.189.45.74/NADRE/1/48/FinalthesisTesfaGeberehiyot.pdf
3. https://iiste.org/Journals/index.php/CER/article/download/44510/45929
4. https://su-plus.strathmore.edu/handle/11071/5640
5. www.fairhavenvt.org/wp-content/uploads/2019/01/Request-for-Proposals-Water-
Meters.pdf
6. https://online-journals.org/index.php/i-joe/article/view/6439
7. https://www.cyberciti.biz/faq/what-is-the-role-of-the-system-administrator/

51