Final Draft

EEPCo NEKEMTE DISTRICT BILLING SYSTEM
CHAPTER ONE
INTRODUCTION
1.1. Background about the organization
Electric Power was introduced to Ethiopian in the late 19th Century, during the regime of Minilik. The
first generator was said given to Minilik around the Year 1898 to light the palace. In addition to the use
of generators ,Minilik got constructed the first Hydro Power Plant on Akaki River in the year 1912 in
order to supply power to small factories that had been limited to small factories and the palace was
extended to public places and major roads in the vicinity of the palace.
In the year 1948, an organization that had been vested with the power to administer the enemy property
was evolved to an organization called Shewa Electric Power. The new organization Shewa although
with limited capacity, managed to increase the power supply not only in Shewa but also other
administrative regions. In light of its function, its name was changed to “Ethiopian Electric light and
Power “in the year 1955.Soon after its establishment, the supervision and management of the
organization was vested in the Board of Directors appointed by the government.
After eight months of its establishment, the Ethiopian Electric Light and Power was transformed to the
“Ethiopian Electric Light and Power Authority” (Charter of the Ethiopian Electric Light and Power).
In order to accommodate the new changes in the environment, the Ethiopian Electric light and Power
Authority was transformed to the Ethiopian Electric Power Corporation (EEPCo) by reorganizing its
functions on the basis of the principles of commercialization and decentralization.
EEPCo Nekemte district is one of district in Oromia region. As our team takes information from the
organization, it was established in 1954. The organization start the administration with few number of
employee‟s, but now a day the organization employee‟s reach 56 in number.
The organization aim to engage in the business of producing ,transmitting ,distributing and selling
electrical energy in accordance with economic and social development policies and priories of the
government and to carry out any other related activates that would enable it achieve its purpose.
JUNE, 2014, INFORMATION TECHNOLOGY DEPARTMENT Page 1

1.2. Introduction about the project
Now a day's technology plays a great contribution on the development of the world. It leads the world
with safe distribution and well defined activities. So in this competitive world doing activities through
computerized way has a great importance over manually inefficiency and effectiveness.
Therefore, the purpose of this project is to develop web based billing system for Ethiopian Electric
Power Corporation (EEPCo) of Nekemte District office and in order to Change its manual system into
automated system. This helps the organization to carry out its tasks in more flexible, fast and well
organized manner. Our team proposes to use different front end and backend software, and minimum
hard ware requirement.
The system we propose helps the organization to register new customer and to use electronic way of
transferring information between district and region office and electronic way of data storage. In
addition, the system has automated way of providing different information such as news and advertises
for customers and users of system.
1.3. Statement of the problem
Currently, EEPCo Nekemte district uses manual system for registering new customer, controlling
payment, controlling penalty. This makes the activities difficult to perform in required time by minimum
man power.
The organization also complete services like bill generation, name transfer, de-enrollment in relation
with regional level and they use hard copy for services information transfer between district and region.
This may lead the organization to many problems like long delay of time to get required service, and
transportation problem.
As a result of existing manual system in the organization, also there is no automated way to announce,
advertise and to update any information related with bill dynamically. And the customer unable to
request complain and related questions in any place. And also customer get difficulty like wasting time
during pay bill.

The organization use traditional file management to store information due to absence of database
management system. This may cause:
 inaccuracy of information(loss of data)
 searching and retrieval of records is time consuming
 requirement of large space for data storage
 difficult in organizing and generating report
So changing the manual system of EEPCo Nekemte district to automated system help the organization
to carry out its tasks in more flexible, fast and well organized manner.
1.4. Objective of project
When the project is initiated it has objectives to be in goal at the end of the project. These are:
 General objective
The general objective of this project is to develop a web based billing system for EEPCo Nekemte
district.
 Specific objectives
Specific objective describe the specific steps to be undertaken so as to achieve the general objective. The
following are the specific objectives which help to achieve the general objective of the project:
 Collecting relevant data and providing means of analyzing the collected data.
 Examine the existing processing system.
 Identify the major problems of the existing system.
 Providing alternative solutions
 Selecting the best solution among the provided alternative solutions.
 Developing and implementing the new system for EEPCo Nekemte District Billing System
1.5. Scope of project

The scope defines the boundaries of the project which part to be studied, analyzed, designed and
implemented. The scope of our project includes the following functionalities:
 Registering new customer
 Payment control
 Penalty control
 Providing automated way of information transfer between district and region for services such as
Name transfer services, De-enrollment service, generate report.
 Providing automated way to retrieve information for required processing.
 Customer complaints and related information request service in anyplace.

 Automated way of announcement, advertisement, news and organizational information
providing.
1.6. Limitation of the project
 The system does not support online payment

 The system also doesn‟t support SMS service.
1.7. Significances of the system
The proposed system will come with a lot of advantage for the organization by solving problems of the
organization that the team members are expressed above in the statement of the problem.
The proposed system gives benefits for both organization and customer and by improving the overall
performance of the organization.
The benefits that the organization will get from the proposed system are:
 Registering new customer in well-defined interface.

 Reducing the time taken to transfer information between region and district level that makes the
customers to get service without waiting long time.
 Storing data in electronics file cabinet (database) that help the organization to store data in easy
and reliable way.
 Retrieving information data easily for required processing.
 Providing bill payment
 Providing bill penalty payment

The benefits that the customer can get from the system are:
 Organizational information and announcement.

 They forward their complain online
1.8. Feasibility Study
Feasibility study is to check the viability of the project under consideration.

1.8.1. Technical feasibility
It is a study of resources availability that may affect the ability to achieve an acceptable system.
This evaluation determines whether the technology needed for the proposed system is available or
not.
This is concerned with specifying equipment and software that will successfully satisfy the user
requirements. The technical needs of the system may include front-end and back-end selection.
An important issue for the development of a project is the selection of suitable front-end and back-
end. When we decided to develop the project we went through an extensive study to determine the
most suitable platform that suits the needs of the organization as well as helps in development of the
project.
The aspects of our study included the following factors.
 Front-end selection:
 It must have a graphical user interface that assists users.
 Must provide excellent reporting features.
 Easy to debug and maintain.
According to the above stated features we selected PHP as the front-end for developing our
project.
 Back-end Selection:
 Multiple user support.
 Efficient data handling.
 Provide inherent features for security.
 Efficient data retrieval and maintenance
 Easy to install.

According to above stated features we selected MySQL as the backend.
1.8. 2. Economic feasibility
With the manual system the operating cost of the system is very high and time consuming. Since the
system reduces time, costs and human power, its value when we compare with existing systems exceeds
in more advantages. Hence the new system is economically feasible.
 Cost Benefit Analysis
We analyzed the costs in terms of tangible and intangible benefits.
 Tangible Cost
The tangible cost of the proposed system contains the following.
 Stationary cost
 Hardware cost
description quantity Unit price in Birr Total

price
Stationery materials - - 150.00
CD ROM disk 10 7.00 70.00
Flash Diskette 4GB 270.00 270.00
Printing cost 400 pages 1.00 400.00
Photo copy cost 50 pages 0.50 25.00
Transport Total trip - 50.00
Photographing cost 10 photos 5.00 50.00
Other Unspecified costs - 250.00
Total 1315.00
Table 1.1. Cost analysis
 Intangible Cost
Intangible costs are costs associated with an information system that cannot be easily measured in Birr
and with certainty such as:
o Development time

o Energy Consumption
1.8.3. Operational feasibility
Purpose projects are beneficial only if they can be turned into information systems that will meet the
organization‟s operating systems. Some of the conditions are:
 Is there sufficient support for the project from management and users?
 Are correct business methods acceptable to the users?
 Have the users been involved in the planning and development of the project.
 Will the proposed system cause harm?
This project is worth full by giving best performance to the bill information, enough throughput as well
as good response time to users. This system ensures to provide safe and secure storage mechanisms for
the confidentiality of bill information.
In general the end-users and the management have a positive attitude toward our proposed system
because it saves time, reduce manual resources and energy.
1.9. Methodology
1.9.1 Data gathering
For gathering the requirement of the system team members will use various types of data gathering ways
interview and observation.
 Interview
To gather more and real information about the EEPCo system we interview employer of the
organization, customers and manager of the organization, and we get lot of information about how their
work, the manager gave us the overall explanation of the system.
 Observation
Our team visualize the ongoing activates of the system and we will try to observe the following things as
mentioned below:
 How they are fast to accomplish their task.

 How the existing system handles and store information.

 What mechanism used to deliver information?
Our team observed the above issues by actual communication with organization and by seeing
information handling techniques.
1.9.2. Analysis and design methodology
The team members use requirement elicitation unified modeling languages to analyze the collected
information. Requirement elicitation helps to discovery system requirement whereas UML is in part of
object oriented approach which is used to specify, visualize, modify, construct and document the
artifacts of an object-oriented software-intensive system under development. We have used Object
Oriented methodology (approach) to develop our system which is now becoming increasingly popular
because of its ability to thoroughly represent complex relationship, as well as to represent data and
process with consistent notation throughout the system. This method provides a powerful environment
for developing complex system. We have selected Object Oriented Analysis since it has so many
advantages over the structured approach which can make our system more efficient.
Object Oriented Analysis design is used to:
 Study the existing system in order to know or learn more about the bottleneck problems.
 Object Oriented Analysis techniques are best suited to projects that will implement a system
using emerging objects technology to construct, manage and assemble those objects in to useful
computer application.
The reason being for using object oriented approach is to get the benefits that we can get from this
methodology such as:-
 Increased reusability
 Increased extensibility
 Improved quality
 Reduce maintenance burden
 simplifies the complex application development
 It creates more flexible application

1.9.3. Implementation methodology
Our team members need to implement the project using PHP, MySQL, HTML, CSS, browser and
Wamp server. We chose PHP because our project goals were ambitious, and we are most comfortable
programming in PHP. There are many advantages offered by PHP it is fast, stable, secure, and easy to
use. By programming in PHP, we were able to work quickly and efficiently and be able to implement
some of our proposed advanced functionality. Wamp Server allows us to create web applications with
PHP and a MySQL database. Alongside, PhpMyAdmin allows us to manage easily our databases.
MySQL database is web hosting database that is used to store web site information like news or user
information. CSS (Cascading Style Sheets) is used for improve and stabilize the attractiveness of the
displayed HTML. A browser allows us for hosting application.
1.10. Hardware and Software Specification
 Hardware consideration
The system can operate on personal computers or laptop having more than70GB hard disk, minimum 1
GB RAM, network interface card, Intel Pentium 2.5 GHz processor on server side and operate on
personal computer or laptop having more than 500MB RAM, Intel Pentium 2.5 GHz processor.
 Software consideration
The system runs in computers must have browser and operating system that support graphical user
interface (GUI) in client side. Also it runs in computers must have browser, operating system that
support GUI and Wamp server.
1.11. Risk and constraint
While we are doing our project we encounter different problems.
 Computer viruses and failures

Action Taken: scanning with anti-viruses and recovering the system.
 Time when power and Computer lab is not available.
Action Taken: Working when the power and computer lab is available.
 Shortage of time while doing our project.
Action Taken: using our time effectively

 The problem of contacting the EEPCo Nekemte District office manager at the time we needed.
The constraints on the development of the system are the following:-
 The requirement will change in time.

 User inability in identifying their real requirements due to barriers in language between the analysts
and customers.
 GUI is only in English language.
 The organization may be unable to buy the necessary hardware and software to run the system.

CHAPTER TWO
INTRODUCTION
In this phase we focus on describing the existing EEPCo billing system of Nekemte district office. It is
so, to study and identify the overview of the existing system, major functions of the existing system with
clear input, process and outputs, business rules of the existing system , alternative solution to address
problems of the existing system , System Requirements of the new system, strength and weakness.
2.1. Overview of the existing system
EEPCo Nekemte district is one of district in Oromia region which works for power distribution among
customer. When customer wants to get services it request the services by filing contract for supply of
electricity form. Once customer fills for supply of electricity form organization employee register
customer information in hard copy and send to region for required service processing. The remaining
services like power improvement, meter change, tariff change are done in similar way.
Customer can forward complain and get any necessary information by communicating directly with
organization. Bill payment and Penalty are performed manually by hard copy.
2.2. Major functions of the existing System with clear input, process and outputs
The major and fundamental functions of the existing EEPCo-billing system Nekemte district are the
followings:
 Customer Registration:-Registering new Customer to the member of the organization.
 Generating reports. ( Bill, customer information)
 Search Customer information
 Bill payment
 Bill penalty payment

2.2.1 Registering customer
Registration of a new customer is major function of the existing system of EEPCo Nekemte district
office. This step is processed by the District officer by exchanging the details of the new customer for
registering to the organization.
 Work flow of registering customer
Having finished and passed through the following procedure; the new customer comes to the office and
take the new customer form and fills necessary information.
 District Officer gives the new customer form for customer.
 Customer fills necessary license information on the form.
 Then the form is checked and submitted to the EEPCo office document.
 Then ID was prepared for the customer.
 The work flow ends when customer takes his/her ID.
2.2.2. Generate reports
The District office is responsible to generate the reports about the bill monthly and annually. This
process starts when necessary information is collected from different customer and user.
 Work flow to report
 Work flow starts by collecting different information from different member.
 Then the District office generates different reports such as amount of bill-cost consumed
electricity power
 Work flow ends after generating necessary reports.
2.2.3. Bill payment
The bill payment is processed at district after it printed by region record officer.
 Work flow to bill payment

 reading data entry and control
 sending District perform meter reading
 meter reading data to region office

 region perform bill calculation and printing

 bill distribution to district
 District collect bill costs.
2.2.4. Bill penalty payment
The bill penalty payment is processed at district level if the customer not pays the bill in a given
duration of days. The payment period of one group if one customer is specified to be 5 days, and
different dates for payment are: 26th-30th, 1th-5th, 6th-10th and 11th-15th of every month in Ethiopia
Calendar.
 Work flow to bill payment

 District officer review the customer's bill
 Check the number or numbers of penalty days.
 Customer gets the penalty form and fills required information.
 Customer pay bill penalty cost to cashier of the organization.
 Customer takes receipt check.
2.3. Business rules of the existing system
A business rule is statement that defines or constrains some aspect of the business. When systems
developed it is needed to respect organization business rules. The following are some of EEPCO
business rules.
 Customer bill generated in region of the nation only.

 Bill must be generated in each month.
 Monthly payment of services must be completed in given duration of days. The payment
period of one group if one customer is specified to be 5 days, and different dates for payment
are: 26th-30th, 1th-5th, 6th-10th and 11th-15th of every month in Ethiopia Calendar.
 Customers provide their full information and payment for new service processing.
 If the customers didn‟t perform payment on time there is penalty of birr.
 To make new registration, to make name transfer (update) the customer must have an ID card.
 The customer must first give all the required valid information and requirements to get access
from the organization.

2.4. Report Generation in the existing System
Reports and summaries are the fundamentals of any business organization. They tell how the business is
running at any given time with specified of summaries.
As report generated in the existing EEPCo, it can be generated based on the general information about
the customer bill. The following are the reports and summaries generated in EEPCo Nekemte district.
 Annual Report: total revenue from bill cost, number of customers and employees.
 Monthly and daily Report: new customer, name transfer, tariff change, bill payment cost, bill
penalty cost.
2.5. Forms and documents used in existing system

In any business documents and forms are the fundamental for the existence of different process. The
existing EEPCo Nekemte system uses the following forms and documents.
 Form of Electricity Sale Bill:-the form that contain bill information like customer name, bill
number, contract number, book-itinerary sequence number, current and previous reading,
consumption, block rate charge birr, etc.
 Form of registration new customer:-the form used for customer registration includes customer
detail like name, address, bill number, contract number, etc.
 Form of penalty payment: - a form that used to pay penalty.
 Form of making name transfer: - a form used when customer want to transfer his/her name to
others.
 Document of meter reading information: - the document that used to store previous and current
metering.
 Document of accepting complain: - a document on which a complain requested by customer is
stored.
2.6. Problems of the Existing System using PIECES frame work

All the task carries out in Nekemte district electric power corporation are not completed in that level
only. All functions are carried out with direct relation with regional level which is found in Jimma. The
organization perform overall organizational activities in manual way. Due to this there are many
drawbacks. The main problems of the existing system are briefly described below:

 Less security and sometime overload of cost.

 Unable to schedule bill circulation date.
 Unable to maintain huge and perfect bill details
 A lot of information is filled redundantly on different forms which is time wasting
 Manual computations, like calculating rate, which are error prone.
 Difficult to generate different types of reports.
 Customer registration service takes log time and difficult to perform easily.
The PIECES frame work was used to identify the problems in the existing manual EEPCO -billing
system of Nekemte district. The problems identified are presented below.
2.6.1. Efficiency related problem
 Employees waste their time due to redundantly input data‟s to register new customer, generating
reports, and calculating cost is erroneous which produce wrong information.
 The use of several forms in the record keeping will incurs additional material cost.
2.6.2. Control and Security problem
 Due to little security control unauthorized workers are capable to access information.
 No use of full format the current system handles.
2.6.3. Input related Problem
All information that must be captured in the current EEPCO Nekemte district is performed manually in
which error may occur and redundant input the information.
2.6.4. Output related problems
 Lack of relevant information in annual and monthly reports generated by the EEPCo-billing system
Nekemte district in calculating bill cost reports. No standard method of generating reports.
 In existing system data is managed using paper sheets which can cause problems like miss
management of data. Cost will be increased because of lot of human resource required for analyzing
data which will lead to time taking process.
2.7. Practice to be preserved from the existing system

Even if the existing EEPCo Nekemte district is running manually it has its own strength, its strengths
must be preserved to enhance the new system. The following strengths are outlined to be preserved in
the automated system.
 For a single customer it has a unique customer number (customer ID).

 Using the customer registration form when customer registered.
 All necessary forms used in the existing system.
 Information that is too sensitive has to be kept in hard copy.
 All necessary reports generated by existing system.
2.8. Weakness and strength of the existing system
 Weakness
 Lack of file security: In the existing system file can easily be damaged and if the file is once
damaged there is no means to get it back.
 Absence of database for file storage
 Difficulty in retrieving of costumer files
 It requires large storing space for record
 Lack of data integrity and leads to information redundancy
 Strength
 Employers try to perform customer services in minimum time by working over the time.
 Because of all needed customers information in hand and the processes proceed in step from one
center to another, easy to fix errors.
 Files are arranged based on the bill registration number.
 They keep the file in category in year-wise in order to make searching files faster as much as
possible.
 Use systematic file searching technique by using bill registration number.
2.9. Alternative Solution to address problems of the existing system
For the existing system our team decided to solve the problem of existing system through web based
system. Because it increases the performance of the existing system by the following factors.

 Short response time for a given piece of work

 High throughput (rate of processing work)
 Low utilization of computing resource(s)
 High availability of the computing system or application.
2.10. System Requirements of the new system
In many organizations, services and tasks the system required to perform can be
Categorized in to functional and non-functional.
2.10.1. Functional requirement of the system
Functional requirements capture the intended behavior of the system. This behavior may be expressed as
services, tasks or functions the system is required to perform. Our system mainly work to remove
services information transfer by hard copy and to bring the fastest services processing. These is done by
providing interfaces for each service and store the data to database so that the information‟s are retrieved
through interfaces. During required elicitation our team observes as well as sort out the following
functional requirement that EEPCo Nekemte district mainly needed to perform.
 The system register new customer for services in well-defined interface.

 The system control payment and penalty process
 The system handles name transfer service information.
The customer can update their information when they want. Many reasons tend one customer to
change his name to another person name. During this time there is needed to have an automated
way to handle the service. During this process removed (de-enrolled) customer data and new
customer data are filled.
 The system handles de-enrollment service information.
While the customer wants to stop using the service permanently can make De-enrollment
processing request. And the organization performs the requested services as needed..
 The system provides Customer complains service. As mentioned above in re-processing service
due to misinformation the processed services are unacceptable by the customers and customers
forward complain. For those cases providing customer complain services is necessary.
 The system provides bill generation

 The system provides report generation

 The system offers customer or district officer to view electricity bill sale
 The system provides different information.
 news
 advertisement and
 Organizational information.
2.10.2. Non-functional requirement of the system
Non-functional requirements are constraints of the system such as response times, computational
accuracy, software portability, scalability, maintainability. The organization customers, the service
users and related personals mainly need system accuracy which reduces many unusual processes. In
addition response time and maintainability is required from system. Due to this our team proposed to
implement the following non-functional requirements.
 The system provides fastest execution speed and reliable system

 The system provide well defined graphical user interface: - well defined graphical user interface
helps the user, customer, system administrator and others to do their own tasks in efficient and
easy way. This is also done by building manageable forms; textbox‟s, labels, buttons and etc.
 The system provide security mechanisms: - the security mechanisms are provided for the system to
protect the system from unauthorized access. Those mechanisms are built by assigning permissions
for system users. The permissions for each users given by system administrator.
 The system provides accuracy: - when the organization performs their tasks the accuracy of the
system was the main consideration. To bring accurate system implementing overall organization
working logic to the right design of the system.
 The system needs minimum hardware and software requirements
 The system helps to retrieve data efficiently

CHAPTER THREE
SYSTEM MODELING
3.1. INTRODUCTION
In this chapter we focus on the system modeling EEPCo billing system of Nekemte district office. It is
so, to study and identify the use case, sequence diagrams, class diagram and business rule of new
system.
3.1.1. Use case identification
A use case represents a function that the system performs. Alternatively, a use case can be thought of as
a goal that some actor can achieve with the system. Identifying use case uses to visualize the overall
system functions and the actors interacting with use cases. By concerning this concept our team
identifies the following use cases.
 Use case
 Login
 View sale bill
 Generate bill
 Pay bill
 Pay penalty
 customer registration
 Make name transfer
 Make de-enrollment
 Generate report
 Forward complain
 Manage user accounts
 Deliver information

3.1.2. Actors specification
Actor classes are used to model and represent roles for "users" of a system, including human users and
other systems. Actors are denoted as stick person icons. In our proposed system there are the actors
which participating with system. The following are the actors of the proposed system.
 Customer: - customer is the primary actor of the system. That mainly requires organization
service by communicating directly to organization employers.
 System administrator: - maintain the system, ensure hardware software working correctly
replying to user comments, control all over the system and data base.
 District Record officer: -District Record officer is also an actor that performs several activity
of the system. She/he accepts complain that come from customer and handle complain
manually. Also she/he provides services like new registration, de-enrollment, make name
transfer, generate bill, report generation for system.
 Region Record officer: -Region Record officer complete all the processes using information
provided by district. In addition to performing requested services it deliver different
information for different personals.
 Cashier: -Cashier collects money payment of bill cost and penalty from customers.
3.1.3. Use case diagram
Use case diagram is used to define the core elements and processes that make up a system. It describes
what a system does from the viewpoint of an external observer. The Use case diagram shows which
actors interact with each use case. Our team designs the proposed system use case diagram as following.

EEPCo Nekemte District Billing System
<<extend>> Pay_penality
Pay_bill
View_sale_bill
Cashier
<<include>>
Advertisements
customer Forward_Complain <<include>>
<<extend>>
name_transfer <<include>>
<<include>> Deliver_information
<<include>>
<<include>> <<extend>>
Rigster _new_cus
login
<<include>> News
Region
De-enrollement record
<<include>>
officer
<<include>>
<<include>>
Generate_bill
District
record
officer
Manage_user_account
Generate report
System Administrator
Fig 3.1.System use case diagram

3.2. Business rule of the new system
The following are some of the business rules which preserve the integrity of the logical data
model of our system.
Name: Only a User with valid username and password can access the system.
Identifier: BR#1
________________________________________________________________
Name: Only System Administrator can manage accounts of other users.
Identifier: BR#2
__________________________________________________________________
Name: Record Officer has the right to access, view and store, the customer‟s record.
Identifier: BR#3
________________________________________________________________
Name: The customer must have bill number to get services provided by
organization.
Identifier: BR#4
________________________________________________________________
Name: customer pay bill in given deadline by the district, else he/she will be pay
penalty payment to the organization
Identifier: BR#5
________________________________________________________________
Name: Only the region record officer can deliver information.
Identifier: BR#6
________________________________________________________________
Name: The District record officer can register customer, make name transfer, make
de-enrollment, generate bill and report.
Identifier: BR#7
________________________________________________________________
Name: Record officer and customer can view electricity bill by using bill number.
Identifier: BR#8
________________________________________________________________
Name: Customer can forward any problem related bill information for organization.
INFORMATION TECHNOLOGY DEPARTMENT Page 22

Identifier: BR#9
3.3.Use case documentation

Login
Name: login
ID: UC-01
Description: To login on the EEPCo Nekemte District Billing System application as valid
User to give service to users.
Participating actor: region record officer, district record officer, customer.
Pre-condition: User must have User name and password.
Basic course of events:
1) The system user wants to login the system.
2) The system displays system login screen.
3) The system user enter user name and password and click submit button.
4) The system validates information according to BR#1.
5) The system displays main menu screen.
6) Use case ends.
Alternate flow A: incorrect user name and/or password.
A.3. The system determines incorrect user name and/ or password entered
A.4. The system informs the user to re-enter user name and/ or password
A.5.the use case resume at step 2 of basic flow
Post-condition: The system user logged.
Table 3.1. Login description
Registration of new costumer
Name: register new customer

ID:UC-02
Description: Act of registering new customer to the system.
Participating actor: customer and district office.
Pre-condition: -District record officer must be logged into system and Customer information

for register.
1) Customer wants to register.
2) District Recorded officer fill the required customer information for registration new
customer on database
3) District record officer click “submit” button
4) If the required information provided by the officer is validated and verified, then customer
will be registered based on business rule given under B#3.
5) The use case ends

Alternate event A: invalid detail information
A.4. the customer will not be registered and the system asks the customer to come with a full
information.
A.5. use case resume at step 2 of basic flow event.
Post-condition: customer will be registered
Table 3.2. Register new customer description
Make De-enrolment
Name: make de-enrolment.

ID: UC-03
Description: the purpose of this use case is to cancel customers from services. And it is
performed by retrieving information from database.
Participating actor: district record officer and customer
Pre-condition: - District record officer must be logged into system and Customer
information for de-enroll.
1) The customer wants to de-enroll.
2) District Recorded officer fill customer information for de-enrollment on database.
3) District record officer clicks on de-enrollment information page link from services
window.

4) The system Fetch information from data base and display the data.
5) District Recorded officer cancel the customer and save into database based on B#7.
6) Use case ends.
Alternate event A: invalid customer information
A.2 the customer information will not be de-enrolled, and the system asks the customer to
full information.
A.3 use case resume at step 2 of basic flow event.
Post-condition: customer de-enrollment confirmation.
Table 3.3. De-enrollment description
Name transfer
Name: Make name transfer

ID: UC-04
Description: the purpose of this use case is to perform name transfer services when
customer needs to change existing detail to another person. And it is performed by
retrieving information saved in database.
Participating actor: district record officer and customer
Pre-condition: district record officer must be logged into system, previous customer
information and new customer detail information.
1) The customer wants to update (change ) the information by other person
2) District Recorded officer fill previous customer information and new customer
information for name transfer on database.
3) District officer clicks on name transfer information page link from services window.
4) The system inserts information into data base.
5) District Record officer process and save the new information according to B#7
6) Use case ends.
Alternate event A: invalid required information
A.2. the customer name transfer will not success, and the system asks the district officer to
fill full information.


Post-condition:-new customer detail.
Table 3.4. Name transfer description
View sale bill
Name: View sale bill

ID: UC-05
Description: this use case helps the customer and District record officer to view sale bill
information.
Actors: customer and District record officer.
Pre-condition: the customer or District record officer must be browsing the system.
1) The customer or district record officer wants to view sale bill information
2) The customer or District record officer clicks on view sale bill page.
3) The customer or District officer enters bill number to view bill information.
4) The system fetches sale bill information from database and displays the data
according to business rule B#8.
5) Use case ends.
Alternate event A: invalid bill number
A.3. the customer bill ID is not found and the system asks the district officer or customer to
enter correct bill ID.
Post condition: view the sale bill information.
Table 3.5.View sale bill description
Generating bill
Name: Generating bill

ID:UC-06
Description: this system is when district office generates bill reports.
Participating actor: District record office.

Pre-condition: -District record officer logged into system and should have to look reading
meter.
1. District record officer want to generate bill.
2. The system displays the Generate bill form
3. The District Record Officer fills all needed information on the form and press Calculate
button supported by B#7.
4. The system checks whether all information is filled and send acknowledgement.
Alternate Flows: Error message
A. 4. The system displays error message if all information is not filled
A.5. The use case resume at step 3 of basic flow event.

Post-condition: The bill is generated
Table 3.6.Generate bill description
Deliver information
Name: deliver information.

ID: UC-07
Description: play crucial role in providing information for the user.
Actor: region record officer.
Pre-condition: - Region record officer must be logged into system and information
1) Region record officer wants to provide information.
2) Region record officer clicks on information providing page and select post
information.
3) Region record officer posts the information according to B#6.
4) The system returns Acknowledgement.

5) Use case ends.

Alternate event A: incorrect information
A.3. If the information will not provide to be posted, and the system asks the region record
officer to refill information.
Post condition: information posting success message.
Table 3.7.Deliver Information description
Forward complain
Name: Forward complain.

ID: UC-08
Description: the purpose of this use case is help customer to forward complain when some
fault is occurred related to bill or meter reading error.
Actor: customer.
Pre-condition: -The customer must be browsing the system and information about the fault
1) The customer wants to send complain about the fault.
2) The customer click on complain page and fill customer detail and it‟s complain.
3) The customer Click on submit button.
4) The system validates the customer information according to B#9.
5) The system response acknowledgement.
6) Use case ends.
Alternate event A: invalid customer information.
A.3 The system display customer detail not found” error message.
A.4 The use case resume at step 1 of basic flow.
Post condition: success message.
Table 3.8.Forward complain description
Generating report
Name: Generating report

ID:UC-10
Description: This process is when the district officer wants to generate report about the tasks
performed at district level for the region.
Participating actor: District record office and region record office.
Pre-condition: District record officer and region record office must be logged into system..
1. District record officer Generate Report about the task performed.
2. The system displays the Generate Report form for District record officer and
enters the required information to the system.
3. The system generates report based on check entered information.
4. The district officer Send button and the systems send the report according
business rule B#7.
Alternate event A: if incorrect required information.

A.2 The system display please ”select service report ” message
A.3 The use case resume at step 2 of basic flow
Post-condition: The report is generated
Table 3.9.Generating report description
Bill payment
Name: Bill payment

ID: UC-11
Description: the purpose of this use case is to pay the bill and it is performed by filling
necessary information asked by system.
Participating actor: Customer, and cashier
Pre-condition: - Cashier must be logged into system, Customer must have bill number.
BR#4
1) The customer wants to pay bill.
2) Cashier select bill payment form from service window and fill customer information

for bill payment.

3) Cashier clicks on submit button.
4) If the required information of customer provided by the Cashier is validated and
verified, then customer will be pay a bill [extension point: pay penalty UC: 13] and
B#5 applied.
5) The use case ends.

A.4 the customer will not pay bill, and the system asks the customer to come with a full
information.
Post-condition: customer will be paid a bill.
Table 3.10.Bill payment description
Pay bill penalty
Name: Bill penalty payment

ID: UC-12
Description: the purpose of this use case is to pay the bill penalty and it is performed by
entering the required information asked by the system.
Participating actor: Customer, and Cashier
Pre-condition: - Cashier must be logged into system.
1) The customer wants to pay bill penalty payment.
2) Cashier fills information for bill penalty payment such as bill number, number of
penalized days.
3) Cashier clicks on submit button.
4) If the required information provided by the Cashier is validated and verified, then
customer will be pay a bill penalty based on B#5.
5) The use case ends.


A.4 the customer will not pay bill, and the system asks the user to come with a full
information.
Post-condition: customer will be paid a bill penalty.
Table 3.11.Pay bill penalty description
Manage accounts
Name: manage accounts

ID: UC-13
Description: this use case helps the system administrator to change, reset, and create new
accounts.
Participating actor: system administrator.
Pre-condition: - System administrator must have an account and must be logged into system.
1) System administrator clicks on manage account link.
2) System administrator fills management detail.
3) System verifies detail according to B#2.
4) Use case ends.
Alternate event A: invalid detail.
A.3 the system displays “invalid detail” message.
Post-condition: success message.
Table 3.12.Manage accounts description
3.4. Sequence diagram

Sequence diagrams are used to formalize the behavior of the system and to visualize the
communication among objects. It represents the interactions that take place among these objects.
Our team first identifies the objects of the sequence diagram and put the interactions through
time lines.

3.4.1. Sequence diagram for login
Fig 3.4.1. Sequence diagram for login

3.4.2. Sequence diagram for customer registration
Fig 3.4.2. Sequence diagram for customer registration

3.4.3. Sequence diagram for de-enrollment
Window Service de-enrolment Form Data Base
District Record Officer
1:click()
2:Display()
3:Fill_Information()
4:Click submit button()
5: if correct fetch name list()

6.Re-fill info()
7:Denrolement()
8:Acknowldgement
Fig 3.4.3. Sequence diagram for de-enrollment information

3.4.4. Sequence diagram for name transfer.

Window Service Name Tansfer Form Data Base
1:click()
2:Display()
3:Fill_Prev_Inform()
5: if correct Insert into DB ()
6:Fill correct info()
7.Ackowlegdment
Fig 3.4.4.Sequence diagram for name transfer

3.4.5. Sequence diagram for view sale bill.
Window Service view sale bill Form Data Base
Customer/District Record Officer
1:click()
2:Display()
3:enter bill id()

if correct id view()
not found id()
6:Acknowldgement
Fig 3.4.5.Sequence diagram for view sale bill

3.4.6. Sequence diagram for bill generate information.

System Bill genarate form Data Base
1.browse()
2. click()
3:Fill Inform()
4:Click calculate button()
5: if correct calculate and store()
6:Fill correct info()
7.Acknowlegdement
Fig 3.4.6.Sequence diagram for bill generation information

3.4.7. Sequence diagram for Deliver information.
system Information Form Data Base
Region Record Officer
1:browse()
2:Click()
3:provide post information()

4.store if fill correct()
5.Refill if not correct()
6:Acknowldgement
Fig 3.4.7.sequence diagram for deliver information

3.4.8. Sequence diagram for forward complain
Fig 3.4.8.Sequence diagram for forward complain

3.4. 9. Sequence diagram for generate report.
Dist_Rec_ Reg_rec-
Officer officer Window Service service form serv_inf_retr_page Data Base
1:click()
2:Display()
3:Fill_ serv_Info()
4:store info()
5:Acknowldgement
6:Click()
7:Display()
8:request report ()
9:Ok()
10:feed reported info()
11:Acknowldgement
Fig 3.4.9. Sequence diagram for generate report

3.4. 10.Sequence diagram for bill payment.
Service Window Pay Bill Form Penalty Bill Form Database Cashier
Cashier
1:click()
2:Display()
3:Fill pymnt Info()

5:if no penality()
7:pay bill()
6:pay penalty()
8:Acknowldgement
9:click()
10:display()
11:fill penalty info()
12:click submit button()
13:pay penalty bill()
14:Acknowldgement
Fig 3.4.10. Sequence diagram for bill payment.

3.4. 11.Sequence diagram for create account.
Fig 3.4.11.Sequence Diagram for create account

3.4. 12.Sequence diagram for update account
Fig 3.4.12. Sequence diagram for update account

3.4. 13.Sequence diagram for resetting passwords
Fig 3.4.13. Sequence diagram for resetting password
3.5. Class diagram

Class Diagram provides an overview of the target system by describing the objects and classes
inside the system and the relationships between them. It represents a relevant concept from the

domain, a set of persons, objects, or ideas. Our team uses class diagram to describe the structure
of the system.
The first for drawing class diagram is to identify classes. After those differentiating relationships,
association, multiplicity and classes operations were the next step to proceed.
Reg_Rec_Officer
-Fname : char Data Base
-Mname : char
-Lname : char
-address : char
+Retrieve report()
+Deliver()
1
1...* Dis_Rec_officer
Penality
Customer -Fname : char
+Date : Date Information 1.* 1 -Mname : char
+Fname : char
-Fixed amount : int 1..* 1..* 1.* 1..* +date : Date -Lname : char
+Mname : char
-reason : char -title : char -address : char
+Lname : char
+pay() -address : char -content : char +register new_cust()
1...* +type : char 1 +make de_enrollement()
+view bill()
1..* +for ward complain() +post() +name transfer()
+pay bill() +accept complain()
1..* +generate report()
1
+genarete bill()
1..* 1..* +view bill()
1..*
Service
1 1..* 1...*
-Name : char
+Type : char
casher 1 1..* Payment +show()
-name : char +date : Date 1..*
+perform penality() -Amount : int
+perform payment() +pay() Complain Account Sys_ Admin
1...* 1
+date : Date -User name : string -Fname
-reason : char -Password : string -Mname
+forward() +create() -Lname
+Manage ()
Fig.3.5.1 class diagram
3.6. Supplementary specification
The major concern in documenting supplementary specification is to capture artifacts where all
requirements that are not contained in use case model, user interface model or domain model.
Supplementary specification includes constraint, change cases and nonfunctional (technical)
requirement.

Supplementary specification for the proposed new system is documented as follows:
 Nonfunctional requirement
 The system should support error handling mechanism.
 The system should be menu driven and attractive.
 The system should protect data from authorized access
 The system should determine users with different privilege.
 Constraints of the new system
Constraint is restriction on the degree of freedom to provide a solution. The following constraints
are outlined for the new billing system of EEPCo Nekemte District.
 The system is not capable of verifying with signature.

 The system will use the data contained MYSQL for the data base.
 The system uses Wamp server for designing User interfaces
 Change cases
In software life time (during operational period) the environment might change with different
aspects, such as technological changes, operation changes additional business units in the
organization.

CHAPTER FOUR
SYSTEM DESIGN
4.1. INTRODUCTION
System design is the transformation of the analysis model into a system design model. It is a
process of defining the architecture, components, modules, interfaces, and data for a system to
satisfy specified requirements. We use system design to reduce the complexity of the system by
decomposing the system into subsystems.
General processes used for system design
 Understand and define the context and the modes of use of the system.
 Design the system architecture.
 Identify the principal objects in the system.
 Develop design models.
 Specify object interfaces.
The system design is essential to determine how we are going to build our system and to obtain
the information needed to drive the actual implementation of our system. The system designer
must decide what performance and characteristics to optimize choose a strategy of attacking the
problem, and make tentative resource allocations.
Design goals
A design goal Describes and prioritizes the qualities that are important for the system .Defines
the value system against which options are evaluated. These goals are derived from the non-
functional requirements of the system.
The following are the qualities of our system that should be considered in designing of the
system. Those are:

 Performance:-The system should respond fast and store large amount of data by using
MYSQL database, it should perform system transaction in a time less than 2 minutes.
 Robustness:-The system should tolerant of misuse by validating input data using
JavaScript language.
 Security:-The system should be secured from unauthorized users by giving special
privilege for authorized users.
 Usability: - The system should have attractive and understandable graphical user
interface.
 Efficient:-the system should be efficient use of memory and CPU by minimizing code
using cascade style sheet.
 Scalability:-the Server should have spare capacity to handle larger number of clients
 Reliability :-the System should survive node or communication link problems
4.2. Class type architecture
Class type
Our system is classified into several related class which are designed to perform different
function.
 User Interface Layer

 Control/Process Layer
 Business/Domain Layer
 Persistent Layer
 System Layer
 User Interface Layer

1. Main user interface
Login class: - This class identify or authorize users for required task when users of the system
wants to login into the system.
Feedback class:- This class of the system store different user‟s feedback that helps to improve
the system to advanced system. Also feedbacks useful for services related tasks.

Contact class:-Contact class contains contact information of the organization.
About Us class: - This class mainly visualizes organization structure. This helps users simply
understand the flow of management.
More link class: - This class contains photo gallery and emergency call.
2. Admin interface
Create account:-Administrator has privileges to create accounts in this class for region and
district record officers and another account for himself.
Update account:-Administrator also has privileges to update accounts when needed by region
and district officers.
Delete account:-This class also deletes accounts of users if it is not required.
3. Customer interface
Bill Information: - This class provides information for customers to view sale bill and how to
pay bill.
Complain: - This class provides the way to forward complain to district and then complains was
processed by region in relation with district officers.
New event: - This class provides new events that may be very urgent information for customers
from organization.
4. Region officer interface
Services information:-This class has separate interfaces to access services information that
provided by district office.
Information: - This class allows the organization to post news, advertisement and events.
File upload: - This class allows offices to upload processed information.
5. District officer interface

Services: - This class holds main functionalities that district office can do. They include bill
payment, bill penalty payment, bill generation, name transfer, make de-enrollment and like.
Downloads: - This class helps the organization to download different types of information
uploaded.
Bill registration:-Bill information of customer is registered because of many operations

performed based on bill information

User interface design
Title
Home Page About Us Feedback Contact More Links
Organization Photo Office phone

structure Emergency
Gallery Numbers
Login
Admin District Officer Region Officer Customer
View sale bill Forward complain

Pay bill
Manage
Accounts View event
Name transfer
Posting News
De-enrollment
Advertise View sale bill
Downloading
Posting Events
Generate bill
Fig 4.2.1 user interface
 CONTROLLER/PROCESS LAYER
The process or controller layer implements business logic that involves collaborating with
several domain classes or even other process classes.
 In this layer our system has one domain that implements the logic of our
system.

 I.e. it is a class with a Name Transfer Information and it is has the

responsibility to check whether the customer is previously registered and if he
is registered it only updates his/her new information.
 BUSINESS/DOMAIN LAYER
The domain or Business layer implements the concepts pertinent to business domain. In our case,
for example, the business domain such as: Customer, Record Officers, and etc. It focuses on the
data aspects of the business objects plus behaviors specific to individual objects.
 This layer implements the concept related to the business domain focusing on the data
aspects of the business.
 PERSISTENCE LAYER
Persistence layer encapsulate the capability to store, retrieve, and delete objects or data
permanently without revealing details of the underlying
This layer summarizes the capability to store, retrieve and delete objects or data permanently
with our revealing details of the underlying storage technology.
Storing the data of the employee and retrieving the datum at needed time is quite possible the
primary key enables the system easily to search.
This layer implements fundamental software features of our projects. The main features of our
project are flexibility and adaptability. It can easily be modified.
 SYSTEM LAYER
System layer provide operating system specific functionality for the applications, isolating the
software from the operating system by wrapping operating system specific features, increasing
the portability of the application developed.
The system is going to be developed using dream weaver by PHP programming language. So the
system can run on the computer that has wamp server. On the other hand for database system
MYSQL is needed to run the system.

 Summarization of class type architecture
Fig 4.2.2 Summarization of class type architecture.
4.3. Class Modeling
Class model provides an overview of the target system by describing the objects and classes
inside the system and the relationships between them. It represents a relevant concept from the
domain, a set of persons, objects, or ideas. Our team uses class model to describe the structure of
the system.

Class models shows the classes of the system, their Interrelationship (including inheritance,
aggregation, and association), and the operations and attributes of the classes.
Reg_Rec_Officer
-Mname : char
-Lname : char Access
-address : char
+Retrieve report()
+Deliver()
1
Provide
Penality
-Fname : char
+Date : Date Customer
Information 1.* 1 -Mname : char
-Fixed amount : int 1..* 1..* -Fname : char 1.* 1..* -Lname : char
+date : Date
-reason : char -Mname : char Can see -address : char e
-title : char g
+pay() -Lname : char
-content : char
Can see
+register new_cust() ana
pay 1...* -m
+view bill() +type : char 1 +make de_enrollement()
+for ward complain() +name transfer()
1..* +post()
1
1..* +genarete bill()
Control 1..* register
+view bill()
pay
Service
req
1 1..* 1...*
1..* -Name : char
ues
+Type : char
t

+name : char +date : Date 1..*
Control +pay()
+perform payment() Complain Account Sys_ Admin
1...* 1
+date : Date -User name : char -Fname : char
-reason : char -Password : char -Mname : char
-manage -Lname : char
+forward() +create()
+Manage ()
Fig 4.3.1. Class model
4.4. Component modeling
Component modeling is an essential part of object oriented system analysis and design.
Components have dependencies on the interfaces of other components, modeled using the
standard UML dependencies
The goal of the system decomposition is to reduce the complexity of design model and to
distribute the class of the system in to large scale and cohesive components. Our system is
decomposing into the following subsystem.

 Services processing subsystem

 Pay bill subsystem
 Pay bill penalty subsystem
 Information providing subsystem
 Complain processing subsystem
 New customer registration subsystem
 Administration subsystem
EEPCo_Billing System
Nekemte District
Adminstration
subSystem communication
subsystem
Service Information Complain Customer

subsystem Pay Bill Pay Bill Penalty Processing registration
subsystem Subsystem Subsystem subsystem
Fig 4.4.1. Subsystem component diagram

4.4. 1. Services information providing subsystem
This subsystem helps the organization to provide various services information that is accessible
by region record officer. In the process the district record officer organize all services
information and feed to system and the region record officer access this information for further
processing. All services have their own interface to put the information‟s.
4.4. 2. Pay bill subsystem
This subsystem allows the organization to perform their payment process in simple manner by
setting duration of payment days.
4.4. 3. Pay bill penalty subsystem

When duration of payment day expire this subsystem provide the way to perform penalty by
filtering list of customers unpaid.
4.4. 4. Information providing subsystem

Organization may have different types of information like news, advertisement, and events.
region record officer provide those information for system. This subsystem allows performing
this functionality.
4.4. 5. Complain processing subsystem

Based on different services given to customer, it may forward complain for district office. So
that, this subsystem can allows the customer to forward their own complain as well as the district
record officer to access and take an action.
4.4. 6. New customer registration subsystem

This subsystem allows district record officer to record customer information that helps for next
processing.
4.4. 7. Communication subsystem

This subsystem helps for conversation between district office and region office by using
message.

4.4. 8. Administration subsystem
This subsystem allows the administrator to authorize users based on privileges level. Admin
create accounts for region and district record officers. In addition to this subsystem allows
account creation for customers.
4.5. Deployment Modeling
Deployment modeling is used to depict the relationship among run-time components and
hardware nodes. Components are self-contained entities that provide service to other components
or actors run-time components.
Client Browsers
<<http>> Application Server

Data Base Server
<<Application>>
Customer Registration
Wamp Server
<<Database>>
EEPCo Billing
<<Application>> System DB
Pay bill
<<Application>>
View Bill
<<Application>>
Forward Complain
<<Application>>
Manage Account
Fig 4.5.1. Deployment model

The system has two nodes the browsers node on the client machine and the database server on
the server computer.
o Browser node:- is to view the Web site by using the website address (URL).
o Client machine: - is user side of the Web.
o database server:- is a computer program that provides database services to other computer
programs or computers, as defined by the client–server model.
4.6. Persistence data management
Persistent data management deals with how the system is going to handle the actual data need to
be stored on the system database. There are currently realistic options for storage management
such as Flat files, Relational database, and Object-oriented database.
From below listed database management systems our team selects relational database
management system to store data. This is because of A relational database provides an
abstraction of data that is higher than flat files. Data are stored in tables that comply with a
predefined type called schema. Each column in the table represents an attribute. Each row
represents a data item as a tuple of attribute values. Several tuples in different tables are used to
represent the attributes of an individual object. Relational databases have been used for a while
and are a mature technology. The use of a relational database introduces a high cost and, often, a
Performance bottleneck. Below there is relationship among tables.

Create Account
First Name(20):char
Customer Midle Name(20):char
Last Name(20):char
Bill No(20): int=Primary Key User Name(20):char
First Name(20):char Create account Password(20):char
Middle Name(20):char Confirm Password(20):char
Last Name(20):char Select Account Type(20):char
Phone Number(10):int
Sex(2):char
Address(30):char Can see Deliver Information
Contract No(20):int
Meter No(20):int Poster(20):char
Book Itinerary No.(20):int Date(10):date
View bill information News(500):char
Fo
pay
rw
ar
d
View Sale Bill

C
om
Bill No(20): int

pl
ai
Bill Payment
n
First Name(20):char
Bill No(20):int Complain Middle Name(20):char
First Name(20):char Last Name(20):char
Middle Name(20):char Bill No(20):int Address(30):char
Last Name(20):char Compinfo(300):char Contract No(20):int
Contract No(20):char Meter No(20):int
Pamount(10):int Book Itinerary No.(20):int
Previous Reading(20):int
Present Reading(20):int
Total Balance(10):int
Fig 4.6.1 Persistent data management
4.7. Hardware /Software Mapping
In order to develop and implement the system software as well as hardware should be
requirements.
 Hardware Mapping
The hardware used for EEPCo-billing system Nekemte district is a personal computer.
 Software Mapping
The system uses Microsoft Windows Professional Operating System. The proposed system uses
Microsoft Dream Waver as a text editor and PHP, JavaScript to develop the system. The system
uses MySQL data base with verterigo/wamp server to store data. Micro soft office 2007 for
documentations

Fig 4.5 Software /hardware mapping
 Client machine: - refers to a user's computer that is connected to a network and accesses the
system from server, machine.
 Web browser: - The application program that serves for accessing the World Wide Web, one
of the major services on the Internet. In order to view a Web site, by using the website
address (URL).
 Server machine: - is a system that responds to requests across a computer network to provide,
the system service.
 Data base: - A MySQL database is a web hosting database that is used to store web site
information like user information.
4.8. Object Design
There are several objects identified in this system. In this section all objects will be described in
detail. The attributes of objects will be described in terms of their purpose, type and constraints
that should on them all the time. In addition to this the conditions that should be satisfied before
an operation is invoked and after it is invoked is also given for each
Revised Class Diagram

Reg_Rec_Officer
-Mname : char
-Lname : char Access
-address : char
+Retrieve report()
+Deliver()
1
Provide
Penality
-Fname : char
+Date : Date Customer
Information 1.* 1 -Mname : char
-Fixed amount : int 1..* 1..* -Fname : char 1.* 1..* -Lname : char
+date : Date
-reason : char -Mname : char Can see -address : char
-title : char ge
+pay() -Lname : char
-content : char
Can see
+register new_cust() ana
pay 1...* -m
+view bill() +type : char 1 +make de_enrollement()
+for ward complain() +name transfer()
1..* +post()
1
1..* +genarete bill()
Control 1..* register
+view bill()
pay
Service
req
1 1..* 1...*
1..* -Name : char
ues
+Type : char
t

+name : char +date : Date 1..*
Control +pay()
+perform payment() Complain Account Sys_ Admin
1...* 1
+date : Date -User name : char -Fname : char
-reason : char -Password : char -Mname : char
-manage -Lname : char
+forward() +create()
+Manage ()
Fig 4.8.1 Revised class model
 Attribute Visibilities and Method description

 Class name: Account
Account
-User name : string
-Password : string
+create()
 Attribute Description for account

o User name: This attribute used to hold the name of a specific user that is trying to create
account.
o Password: This attribute used to hold the password or the validation key of the user that
has been used as the first criteria to create account

 Method Description
o Create (): Used to create account.
 Visibility: private.
 Class name: System administrator
Sys_ Admin
+Fname
+Mname
+Lname
+Manage ()
 Attribute Description for system administrator

o First name: Used to hold the first name of the user in the system.
o Middle name: Used to hold the middle name.
o Last Name: Used to hold the last name
o Manage (): used to manage account (create account, delete account and update account).
 Class name: customer
Customer
+Fname : char
+Mname : char
+Lname : char
-address : char
+view bill()
+for ward complain()
+pay bill()
 Attribute Description for Customer

o First name: The first name of the person.
o Middle name: Middle name of the person.
o Last name: Last name of the person.
o Address: Holds the address of a customer(phone number, e-mail)
o View bill (): Used customer to view electricity sale bill information.
o forward complain (): This operation used to forward complain when some fault is
occurred related to bill or meter reading error.

o Pay bill (): This method helps customer to pay bill.

 Class name: District Record officer
Dis_Rec_officer
-Fname : char
-Mname : char
-Lname : char
-address : char
+register new_cust()
+make de_enrollement()
+name transfer()
+accept complain()
+generate report()
+genarete bill()
+view bill()
 Attribute Description for District Record officer

o First name: Used to hold the first name of the district officer in the system.
o Middle name: Used to hold the middle name of the officer.
o Last Name: This attribute used to hold the last name of the officer.
o Address: Holds the address of a district record officer(phone number, e-mail)
o Register new customer (): This operation used to register new customer.
o Make de-enrollment (): This method used to cancel customers from services.
o Name transfer (): This operation used to perform name transfer services when customer
needs to change existing detail to another person.
o Accept complain (): This operation used to accept request from customer about the faults
occurred.
o Generate report (): This operation used to generate report about the tasks performed.
o Generate bill (): This operation used when district office generate bill.
o View bill (): This operation helps district officer to view electricity sale bill information.
 Class name: Region Record officer

Reg_Rec_Officer
-Fname : char
-Mname : char
-Lname : char
-address : char
+Retrieve report()
+Deliver()
 Attribute Description for District Record officer

o First name: This attribute used to hold the first name of the region record officer in the
system.
o Middle name: Used to hold the middle name of the officer.
o Last Name: This attribute used to hold the last name of the officer.
o Address: Holds the address of a region record officer(phone number, e-mail)
 Operation Description
o Retrieve Report (): This method helps region record officer to view report generated from
district record officer.
o Deliver (): This operation used to deliver information such as posting news and vacancy.
 visibility: private
 Class name: bill payment
Payment
+date : Date
-Amount : int
+pay()
 Attribute Description for bill payment

o Date: This attribute used for specifying the date at which the payment was done.
o Amount: This attribute used for the amount of total payment.
o Pay (): This method helps customer to pay cost of bill.
 Class name: bill penalty

Penality
+Date : Date
-Fixed amount : int
-reason : char
+pay()
 Attribute Description for bill penalty

o Date: This attribute used for specifying the date at which the penalty was done.
o Fixed amount: This attribute used for specifying the original amount of payment before
penalty is occurred.
o Reason: This attribute used for the reason penalty is occurred.
o Pay (): This method helps customer to pay cost of bill penalty.
 Class name: service
Service
-Name : char
+Type : char
+show()
 Attribute Description for service

o Name: This attribute used to hold the name services listed on service window such as
deliver information and tariff change.
o Type: This attribute used for specifying the type service. I.e. deliver information or tariff
change.
o Show (): This method used to display type of services.
 Class name: Information
Information
+date : Date
-title : char
-content : char
+type : char
+post()
 Attribute Description for information

o Date: This attribute used for specifying the date at which the information was delivered.
o Title: This attribute used for specifying the title information to be delivered.
o Content: This attribute used for specifying the content of information to be delivered.
o Type: This attribute used for specifying the type information. I.e. news, vacancy or new
events.
o Post (): This method used to post information.
 visibility: public
 Class name: casher
casher
+name : char
+perform penality()
+perform payment()
 Attribute Description for casher

o Name: This attribute used to specify the name of the casher.
o Perform penalty (): This method helps casher to collect payment of bill from customers.
o Perform payment (): This method helps casher to collect penalty birr from customers.
 Class name: Complain
Complain
+date : Date
-reason : char
+send()
 Attribute Description for information

o Date: This attribute used for specifying the date at which the information was delivered.
o Reason: This attribute used for specifying the default that customer get.
o Send (): This method used to send complain.
 visibility: public

Chapter Five
5. Implementation
5.1. Introduction
Implementation in the system includes implementing the attributes and methods of each object
and integrating all the objects in the system, to function as a single system. The implementation
activity spans the gap between the detailed object design model and a complete set of source
code files that can be compiled together. This chapter presents Algorithm design & coding.
5.2. Algorithm Design and coding
For controller class member function algorithm are designed. This design enables to see every
steps and flow of logic in each function. This design part is important in the coding part of
implementation. Some of the algorithms are:
5.2.1. Algorithm
Algorithm for log in to the user home page
Display Administrator main form
Fill user name, password and user type in the appropriate interface
If the filled input is valid
Display user main page
Else
Display Error Message and return to home page
End if
Algorithm for Customer registration
Display Main page
Fill user name and password in the appropriate interface
Display main form

If user selection is Customer registration
Display Customer registration form
Fill the necessary input in the appropriate interface
Record the Customer information to database ()
Else
Display Error message ()
End if
Else
Return to main form
End if
Else
Display Error Message and return to login form
End if
Algorithm for forwarding feedback
Display feedback form
Fill user name and write comment in the appropriate interface
Display posted comments
Else
Display Error Message and return to home page
End if

5.2.2. Coding
Login:
Used to authenticating users.
<form action="login.php" method="POST" onsubmit="return check();" name="login">
<fieldset id="fieldsetle">
<legend>Member Login</legend><br>
             <input
style="height: 32px;"class="box11" type="text" name="uname" size="30" placeholder="Enter
your user name here"><br><br>
          <input
type="password" style="height: 30px;"class="box11" name="psswrd" size="30"
placeholder="Enter your pasword
here"><br><br>          &nbsp
;

<select name="actype" id="actype" >
<option value="" disabled="disabled" selected="selected">Select Acount Type</option>
<option value="admin">Administrator</option>
<option value="doff">District officer</option>
<option value="roff">Region Officer</option>
<option value="cust">Customer</option>
</select><br><br>




<inputclass="groovybutton" type="submit" name="pass"

value="Login"><p>          &n

bsp;

<a href="forgot.php">Forgot password?</a></p>


<a href="cust.php">New customer?</a>
<div id="error" style="color:red"></div>
</fieldset>
</form>
Fig 5.1 Login form
New customer account:
<div id="maina">
<form action="custp.php" method="POST" name="newcus" onSubmit="return

check1();">
<fieldset style="width:500px; height:400px;">
<legend>New customer</legend>

<center>Customer Bill No:   <input type="text" name="cubilno"

onSubmit="return checkbillno();"></center><br><br>
<center>User Name:

<input type="text" name="nam"></center><br><br>
<center>Your child name:
<input type="text" name="chnam" onKeyPress="return

isNumberKey(event)"></center><br><br>
<center>Password:         &nb
sp;
<input type="password" name="paswrd"></center><br><br>
<div id="error1" style="color:red"></div>
<center><input class="groovybutton" type="submit" value="creat">
<input class="groovybutton" type="reset"></center>
</fieldset>
</form>
</div>

Fig 5.2 New customer form
Feedback:
User forwards any feedback using this interface.
<form action="login.php" method="POST" onsubmit="return check();" name="login">
<fieldset id="fieldsetle">
<legend>Member Login</legend><br>
             <input
style="height: 32px;"class="box11" type="text" name="uname" size="30" placeholder="Enter
your user name here"><br><br>
           <input

type="password" style="height: 30px;"class="box11" name="psswrd" size="30"
placeholder="Enter your pasword here"><br><br>


<select name="actype" id="actype" >
<option value="" disabled="disabled" selected="selected">Select Acount Type</option>
<option value="admin">Administrator</option>

<option value="doff">District officer</option>
<option value="roff">Region Officer</option>
<option value="cust">Customer</option>
</select><br><br>



<input class="groovybutton" type="submit" name="pass"

value="Login"><p>          &n
bsp;

<a href="forgot.php">Forgot password?</a></p>



<a href="cust.php">New customer?</a>
<div id="error" style="color:red"></div>
</fieldset>
</form>

Fig 5.3 Feedback form
5.3. Test Procedures
Unit testing
Verification (A set of operations that the software correctly implemented a particular function)
on the smallest element of the program i.e. the modules are tested alone in order to discover any
error in the code.
Some of errors that controls are
 When the field is empty, the system will display the following message.
Login: incorrect output.

Fig 5.4 Incorrect login form
 When we enter a character instead of numeric value, the system will display the following
message
Fig 5.5 Only number form

 When we enter a number instead of character value, the system will display the following
message
Fig 5.6 Only alphabet form

Upload file:error in uploading file.
Fig 5.7 Upload files form
 The system calculates average cost of the bill by accepting current and previous read amount.
If previous reading is greater than the current the system display the following message.

Fig 5.8 Bill calculation error form
Integrated testing
The process of bringing together all the modules that a program comprises for testing purpose.
System testing
System test insures that the entire integrated software system meets requirements. It tests a
configuration to insure known and predictable results. System testing is based on process
description and flows, emphasizing pre-driven process links and integration points.
In essence system testing is not about checking the individual parts of design, but about
checking the system as a whole. In effect it is one giant component.
System testing insures the following have been met correctly.
They are:
• Functional requirements
• Non Functional requirements such as
Performance –Are the performance criteria met?
The performance of our system is met so performance is fulfilled.
Volume-can large volumes of information are handled?
Large volume of information can be handled in our system.
Documentation-Is the documentation usable for the system?
The documentation can be used as a guide for the user of the system.
Robustness-Does the system remains stable under adverse circumstances?
Volume Testing
The purpose of volume testing is to find weakness in the system with respect to its handling of
large amount of data during extended time periods.
Acceptance testing

The process by which the actual users test a completed information system, the end result of
which is the user acceptance of the system. Acceptance testing checks the system delivers what
was requested.
5.4 User Manual Presentation
The EEPCo-billing System Nekemte district gives different services to the users of the system.
In order to guide the users and to interact with system functionality, the system user manual is
prepared. . It covers issues such as how to add a new bill and customer, how to view bill
information and customer information, how to search specific bill and search specific customer,
delete unwanted bill, how to calculate bill cost and generate bill calculated. The various forms
that are included in the system are shown with their description as follows.
To Start the System
Fig 5.9 Home page form
The first form which will be displayed when the user opens the EEPCo-billing System Nekemte
district application program is the log in form

Fig 5.10 Login form
This form is used to validate whether a specific user is authorized to use the EEPCo Nekemte
district billing system or not. The authorized users of the system will enter the user name on the
text field next to user name and the password on the text field next to password. After the data
for the two fields are inserted the user can press the “ok” button to log in to the system or cancel
button to exit the login form and quit using the application.
If you insert a correct password and username information message will be displayed as below.

Fig 5.11 Home form
If you insert an invalid password and username error message will be displayed as described
below
Fig 5.12 Incorrect username or password form

To register bill customers
To register a customer‟s bill , the district officer click open his home page then select bill
registration and then register button of the home form and the system display the following
registration form then fill all information and click register submit to save into database
Fig 5.13 Bill registration form
How to generate Reports
To generate different types of reports select from dropdown menu the Reports button in the
main form and the following form will be displayed.

Fig 5.13 Generate report form
To Create New User Account
To create user account, the Admin clicks on the create account button and the system display the
following Create Account form
Fig 5.14 Create account form

To update or change account

In order to change existing account information, user clicks on the update account button of
the home form and then clicks on update button and the system display the following update
account form.
Fig 5.15 Update account form
To view bill Information

In order to view existing customer information, the district officer/costumer click on the view
text box and user enter bill number of the home form and the system display the following
information bill form.

Fig 5.16 View bill information form
To view an existing customer bill information use the following steps
1. Click on check text box to view bill information

2. then, insert bill id to search the existing customer information
3. Enter. If the searched bill number is invalid or doesn‟t exist the system display “bill information is
not found ".
To de-enrollment/ delete bill Information

In order to delete existing customer information, the district officer click on the delete button of
the home form and the system display the following delete customer form.
Fig 5.17 Delete bill information form
To delete an existing customer information use the following steps
1. select bill de- enrollment button on home form

2. After the form is displayed, insert customer bill id.
3. After getting id click on Delete button
4. To reset the form click on reset button.
5.5 Hardware software acquisition
For the proper functioning of the system the following hardware and software are required
 Hardware’s
 Computer
 CD/DVD disk, magnetic tape, for recovery.

 Software’s
 Macromedia Dreamweaver MX 2004(or above)
 Wamp Server
 Internet Explorer
 Mozilla Firefox
5.6. Installation
After installing both Macromedia Dreamweaver and vertigo server software do the following
steps
Step1
 Get the folder “EEPCO “from the Developing Team.
Step 2
 Copy the folder to WWW folder in the c:\programfiles\wamp
Step3
 Explore internet explorer and import the database “EEPCOO” into data folder
http://localhost/phpmyadmin/ to create database called „EEPCOO‟
Step4
 Run Wamp server

Step5
 Finally, log in with your account so, installation is finished
5.7 Startup Strategy

Steps1
 Activate Wamp server from the Desktop or Start up Menu if it‟s not activated.
Click on start ->Wamp server

Then Click on “Start All Services and start server”
Then
Step2
From the start menu click on start->Run

Steps3
In the run Dialog box type the URL of the page (http://localhost/eepco/login.php) and the
click “OK” button.

CHAPTER SIX
CONCLUSION AND RECOMMENDATION
6.1. Conclusion
An effort has been made to study EEPCo Nekemte District as partial fulfillment of BSc degree in
information Technology. In doing the study the team has tried to follow object oriented system
analysis and design methodology.
Since the success and failure of any system depends on gathering the right information through
different fact-finding techniques and user involvements, the team has made the best effort to
gather requirements. After a detail review and study of the existing system of EEPCo Nekemte
District models have been designed to reflect the new system that is supposed to solve problems.
Designing computerized system for EEPCo Nekemte District helps to maintain a computer based
billing system.
In order to solve different problems existed the team has tried to propose a solution that at least
reduce the existed problems and model the proposed system using different tools and
methodologies. We believe that different tools and techniques has helped us a lot in capturing
real user requirements and model the right system for the users for their day to day transactions.
Thus it should have the precedence in know-how and experience in collecting, processing and
utilizing information.
6.2. Recommendation
Nowadays, the world is highly becoming a competitive world. Organizations have to divert their
attention on using the recent technology to be on the first line and competitive. This can be real if
they are able to use information communication technology (ICT) to successfully achieve their
objective. EEPCo Nekemte District is the Government institution that includes many human
powers in fulfilling its function. This is mainly concerned with providing Human power. As we

describe in this document, almost all activities of the organization is done on manual basis. From
the various facts that constitute the project, the following points can be recommended:
 Attention should be given to the existing practice in the design, development and
utilization of the new system.
 Serious consideration should be given for the introduction of the new system.
 The staff workers should have adequate computer facilities for the introduction of the
new system.
 Behavioral change of the users of the system to adapt the new system.
 There should be a network infrastructure in order to connect the different computers in
the department.
 Budget should be allocated to take specific measure:
- To change the obsolete hardware instrument by the new one.
- To avoid shortage of computer hardware equipment like printer,

scanner and others.
- To have standardize database.
Appendix
References
1. Ambler, Scott, and W...Object primer 2nd ed. Cambridge: Cambridge University
press (2001).
2. Elmasri, Ramex.Fundamentals of database systems.2nd.ed.Redwood city, CA:
Benjamin Cummings publication.
3. Jacobson, Ivar. Software Engineering. New York: McGraw-Hill (1992).
4. System analysis and design with UML 2nd edition,1994
5. www.freesoftware.com
6. www.sourcecodester.com

Final Draft

Uploaded by

Copyright:

Available Formats

Final Draft

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Draft

Uploaded by

Copyright:

Available Formats

EEPCo NEKEMTE DISTRICT BILLING SYSTEM

1.1. Background about the organization

JUNE, 2014, INFORMATION TECHNOLOGY DEPARTMENT Page 1

1.2. Introduction about the project

for customers and users of system.

1.3. Statement of the problem

JUNE, 2014, INFORMATION TECHNOLOGY DEPARTMENT Page 2

 inaccuracy of information(loss of data)

 searching and retrieval of records is time consuming

 requirement of large space for data storage

 difficult in organizing and generating report

1.4. Objective of project

1.5. Scope of project

JUNE, 2014, INFORMATION TECHNOLOGY DEPARTMENT Page 3

 Customer complaints and related information request service in anyplace.

1.6. Limitation of the project

 The system does not support online payment

1.7. Significances of the system

 Registering new customer in well-defined interface.

JUNE, 2014, INFORMATION TECHNOLOGY DEPARTMENT Page 4

 Organizational information and announcement.

1.8. Feasibility Study

Feasibility study is to check the viability of the project under consideration.

JUNE, 2014, INFORMATION TECHNOLOGY DEPARTMENT Page 5

According to above stated features we selected MySQL as the backend.

1.8. 2. Economic feasibility

The tangible cost of the proposed system contains the following.

description quantity Unit price in Birr Total

JUNE, 2014, INFORMATION TECHNOLOGY DEPARTMENT Page 6

1.8.3. Operational feasibility

because it saves time, reduce manual resources and energy.

1.9.1 Data gathering

 How they are fast to accomplish their task.

JUNE, 2014, INFORMATION TECHNOLOGY DEPARTMENT Page 7

 What mechanism used to deliver information?

1.9.2. Analysis and design methodology

Object Oriented Analysis design is used to:

JUNE, 2014, INFORMATION TECHNOLOGY DEPARTMENT Page 8

1.9.3. Implementation methodology

1.10. Hardware and Software Specification

1.11. Risk and constraint

While we are doing our project we encounter different problems.

 Computer viruses and failures

JUNE, 2014, INFORMATION TECHNOLOGY DEPARTMENT Page 9

 The requirement will change in time.

JUNE, 2014, INFORMATION TECHNOLOGY DEPARTMENT Page 10

2.1. Overview of the existing system

 Customer Registration:-Registering new Customer to the member of the organization.

 Generating reports. ( Bill, customer information)

 Search Customer information

 Bill penalty payment

JUNE, 2014, INFORMATION TECHNOLOGY DEPARTMENT Page 11

2.2.1 Registering customer

 Work flow of registering customer

 District Officer gives the new customer form for customer.

 Customer fills necessary license information on the form.

 Then ID was prepared for the customer.

 The work flow ends when customer takes his/her ID.

2.2.2. Generate reports

 Work flow to report