Final Project of Centralized Bill System

Centralized Billing System
Acknowledgment
First of all, we would like to thank our God, who gives us love, patience, healthy, wisdom and
ability to walk through all the problems and obstacles during the period of our study. Secondly
we want to express our deepest appreciation and gratitude to our advisor Mr. Bekele Worku for
his great contribution with necessary correction and advice in our project what we have to do
timely and effectively. Thirdly, we would like to express our special words of gratitude to Dilla
town Telecom, Water and Electric service organization that helped us by providing information
and by giving useful documents and materials that are useful for our project. In addition we will
give great thanks for all our friends to help us by giving information and moral for success
completion of this project.
I
Table of Contents
Acknowledgment..........................................................................................................................................I
List of Figures.............................................................................................................................................V
List of Table..............................................................................................................................................VII
Acronym..................................................................................................................................................VIII
Abstract.......................................................................................................................................................X
CHAPTER 1 INTRODUCTION.............................................................................................................- 1 -
1.1 Background of the organization.....................................................................................................- 1 -
1.2 Introduction about the project........................................................................................................- 2 -
1.3. Statement of the problem..............................................................................................................- 2 -
1.4 Objective of the project.................................................................................................................- 3 -
1.4.1. General objectives.................................................................................................................- 3 -
1.4.2. Specific objective...................................................................................................................- 3 -
1.5 Scope and Limitation.....................................................................................................................- 3 -
1.5.1 Scope of the project...............................................................................................................- 3 -
1.5.2 Limitation of the project.........................................................................................................- 4 -
1.6 Methodology.................................................................................................................................- 4 -
1.6.1 Data gathering methodology..................................................................................................- 4 -
1.6.2. Design methodology..............................................................................................................- 5 -
1.6.3. Implementation methodology...............................................................................................- 5 -
1.6.4 Testing methodology..............................................................................................................- 6 -
1.6.5. Development environment and programming tool...............................................................- 7 -
1.6.5.2. Object Oriented Design (OOD.............................................................................................- 7 -
1.7. Feasibility study...........................................................................................................................- 9 -
1.7.1 Technical Feasibility................................................................................................................- 9 -
1.7.2 Operational Feasibility..........................................................................................................- 10 -
1.7.3 Economic feasibility..............................................................................................................- 10 -
1.9. Project schedule (using Gantt chart)...........................................................................................- 11 -
CHAPTER 2 EXISTING SYSTEM......................................................................................................- 12 -
2.1. Introduction of Existing System.................................................................................................- 12 -
2.2. Description of existing system....................................................................................................- 12 -
2.3. Limitation of the existing system................................................................................................- 12 -
II
2.3.1 Performance (Response time)..............................................................................................- 13 -

2.3.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate)..........................................- 13 -
2.3.3 Security and Controls............................................................................................................- 13 -
2.3.4 Efficiency..............................................................................................................................- 13 -
2.4 Model of Existing System...........................................................................................................- 14 -
2.4.1 Actor.....................................................................................................................................- 14 -
2.4.2 Essential use -case................................................................................................................- 14 -
2.5 Business rules..............................................................................................................................- 16 -
CHAPTER 3 PROPOSED SYSTEM....................................................................................................- 17 -
3.1 Overview of the proposed system................................................................................................- 17 -
3.2 Requirements of the Proposed System........................................................................................- 18 -
3.2.1 Functional Requirements......................................................................................................- 18 -
3.2.2 Non-Functional Requirements..............................................................................................- 18 -
3.2.3 System Requirement............................................................................................................- 19 -
3.3 User Interface Specification and Description..............................................................................- 21 -
CHAPTER 4 SYSTEM MODELING...................................................................................................- 23 -
4.1 Introduction.................................................................................................................................- 23 -
4.2 Use case diagrams.......................................................................................................................- 23 -
4.2.1 Use case description.............................................................................................................- 24 -
4.3 Sequence diagram........................................................................................................................- 33 -
4.4 Activity Diagram.........................................................................................................................- 42 -
4.6 Database specification.................................................................................................................- 49 -
4.6.1 E-R Diagram..........................................................................................................................- 52 -
CHAPTER FIVE SYSTEM DESIGN...............................................................................................- 53 -
5.1 Introduction.................................................................................................................................- 53 -
5.1.1. System Overview.................................................................................................................- 53 -
5.1.2. Design Goal..........................................................................................................................- 53 -
5.1.3. Architecture of the System..................................................................................................- 54 -
5.2 System Design.............................................................................................................................- 56 -
5.2.1 Subsystem decomposition....................................................................................................- 56 -
5.2.2 Component diagram.............................................................................................................- 58 -
5.2.3 Hardware and Software mapping.........................................................................................- 59 -
5.2.4 Deployment Diagram............................................................................................................- 60 -
III
5.3 Detailed Design...........................................................................................................................- 61 -

5.3.1 Package diagram...................................................................................................................- 61 -
5.3.2 Collaboration diagram..........................................................................................................- 62 -
5.4 User Interface design...................................................................................................................- 64 -
5.5 Access control and Security.........................................................................................................- 68 -
CHAPTER SIX: IMPLEMENTATION................................................................................................- 69 -
6.1 Objective of implementation.......................................................................................................- 69 -
6.2 Hardware and Software Acquisitions..........................................................................................- 69 -
6.3 User Manual Preparation.............................................................................................................- 70 -
6.4 Algorithm and Outputs................................................................................................................- 70 -
6.4.1 Sample Code.........................................................................................................................- 70 -
6.5.2 Sample Results......................................................................................................................- 73 -
CHAPTER SEVEN: TESTING............................................................................................................- 74 -
7.1 Introduction.................................................................................................................................- 74 -
7.2 Unit Testing and Result...............................................................................................................- 74 -
7.3 Integrated Testing........................................................................................................................- 75 -
7.4 System Requirement Testing and Results....................................................................................- 75 -
CHAPTER EIGHT: CONCLUSION AND RECOMMENDATION....................................................- 76 -
8.1 Conclusion...................................................................................................................................- 76 -
8.2 Recommendation.........................................................................................................................- 77 -
9. Reference..........................................................................................................................................- 78 -
10. Appendix.........................................................................................................................................- 79 -
10.1 Appendix A: Interview Questions.............................................................................................- 79 -
10.2 Appendix B: Symbol and Description.......................................................................................- 80 -
IV
List of Figures
Figure 1. Essential use case Telecom.......................................................................................- 14 -
Figure 2. Essential use case of water service...........................................................................- 15 -
Figure 3 . Essential use case of Electric service.......................................................................- 15 -
Figure 4. User interface specification......................................................................................- 21 -
Figure 5. Use case diagram......................................................................................................- 23 -
Figure 6. Sequence diagram for login......................................................................................- 33 -
Figure 7. Sequence diagram for create account.......................................................................- 34 -
Figure 8. Sequence diagram for update account.....................................................................- 35 -
Figure 9.Sequence diagram for delete account........................................................................- 36 -
Figure 10. Sequence diagram for check payment.....................................................................- 37 -
Figure 11. Sequence diagram for prepare bill.........................................................................- 38 -
Figure 12. Sequence diagram for generate report...................................................................- 39 -
Figure 13.Sequence diagram for payment................................................................................- 40 -
Figure 14. Sequence diagram for view report..........................................................................- 41 -
Figure 15. Activity diagram for login.......................................................................................- 42 -
Figure 16. Activity diagram for create account........................................................................- 43 -
Figure 17. Activity diagram for update account.......................................................................- 44 -
Figure 18. Activity diagram for delete account........................................................................- 45 -
Figure 19. Activity diagram for generate report......................................................................- 45 -
Figure 20. Activity diagram for prepare bill............................................................................- 46 -
Figure 21. Activity diagram for pay money.............................................................................- 47 -
Figure 22. Class Diagram........................................................................................................- 48 -
Figure 23. E-R Diagram...........................................................................................................- 52 -
Figure 24 Architecture of the system........................................................................................- 55 -
Figure 25 Subsystem diagram...................................................................................................- 57 -
Figure 26 Component modeling diagram.................................................................................- 58 -
Figure 27 Hardware-software mapping....................................................................................- 59 -
Figure 28 Deployment diagram................................................................................................- 60 -
Figure 29 Package diagram.......................................................................................................- 61 -
Figure 30 collaboration diagrams for registration.....................................................................- 62 -
V
Figure 31 Collaboration diagrams for view report....................................................................- 63 -

Figure 32 User interfaces for home page..................................................................................- 64 -
Figure 33 User interfaces for Login page.................................................................................- 65 -
Figure 34 User interfaces for Admin page................................................................................- 66 -
Figure 35 User interfaces for Employee page...........................................................................- 67 -
Figure 36 User interfaces for Customer page...........................................................................- 68 -
Figure 37 sample output of Pay online page.............................................................................- 73 -
Figure 38 Unit testing.............................................................................................................- 74 -
VI
List of Table
Table 1 . Task and Schedule......................................................................................................- 11 -
Table 2. Use case for log in......................................................................................................- 24 -
Table 3. Use case for update account.......................................................................................- 25 -
Table 4 Use case for delete account.........................................................................................- 26 -
Table 5 Use case for check payment.........................................................................................- 27 -
Table 6. Use case for create Account.......................................................................................- 28 -
Table 7. Use case for generate report.......................................................................................- 29 -
Table 8. Use case for payment..................................................................................................- 30 -
Table 9. Use case for prepare bill.............................................................................................- 31 -
Table 10. Use case for view report...........................................................................................- 32 -
Table 11. Table of bank.............................................................................................................- 49 -
Table 12. Table of Water service..............................................................................................- 50 -
Table 13. Table of Telecom service..........................................................................................- 50 -
Table 14.Table of Electricity service........................................................................................- 51 -
Table 15. Table of bill report....................................................................................................- 51 -
Table 16 Symbol and Description.............................................................................................- 80 -
VII
Acronym
CBE-Commercial Bank of Ethiopia.
CBS-Centralize Billing System

CD-Compact Disk.
CPU-Control Processing Unit.
DBMS-Database Management System.
DFD-Data Flow Diagram.
DHTML-Dynamic Hyper Text Markup Language.
ER- Entity Relationship.
GB-Giga Byte.
GUI-Graphical User Interface.
HTML–Hypertext Markup Language.
ID-Identification Number.
IE-Internet Explorer
MYSQL-My Structural Query Language.
OOA – Object Oriented Analysis.
OOD –Object Oriented Design.
OOSAD-Object Oriented System Analysis Development
OOSD –Object Oriented System Development.
PC-Personal Computer.
VIII
PHP- Hypertext Preprocessor.
RAM-Random Access Memory.
SNNPRS - South Nation Nationality and People Regional State.
SQL- Structural Query Language.
SRS-System Requirement Specification.
UI-User Interface.
UML-Unified Model Language.
XML-Extensible Markup Language.
XAMPP- Cross-Platform (X), Apache (A), MySQL (M), PHP (P) and Perl (P).
IX
Abstract
In this project, we propose a new model for centralized billing system for personal bills
such as water bills, telecom bills and electric bills. The proposed system consolidates all
bills for one user so the user will not need to track and pay the bills individually. Personal
users can save a lot of time and effort on paying bills every month and will less likely forget to
pay for the bills thus avoiding paying late payment fines. Billing organizations such as utility
companies, telecom companies and banks can benefit from this system by getting payments from
users in time and sending out less physical mails for bills, which can save a lot of costs as well
as save the resources.
The proposed system can also provide functionalities for the users to track and view
their expenses back in time and in different aspects online from anywhere. Expense
reports can also be generated for all bills monthly, which is a very useful tool for user to know
and plan their expenses. Generally, the main goal of centralized billing system is to shorten
processing time, to reduce errors, to improve the accuracy of input and to change the manual
data handling system into automated system.
X
CHAPTER 1
INTRODUCTION
1.1 Background of the organization
Now a day, most people are having familiarity with computer and computer based application.
Many organization and individuals have their computer based applications for the purpose of
running their business, to perform different activity. The aim of this project is to develop
centralized billing system for Dilla town.
Dilla town is found 360 kilometers far from the capital city of Ethiopia. It is one of the towns in
South Nation Nationality and People Regional State (SNNPRS) having different culture and its
center of trade in the region. It has its own administration structure to organize, control and
manage the local communities. In Dilla town there are governmental and nongovernmental
organizations which facilitate the development of the town and provide services to the
community. From those governmental organizations Electric Corporation, Telecommunication
and Water Service are found in Dilla town. All these organization uses manual type of billing
system. All this is to propose a governmental organization that provides billing system service
for Telecom, Electric Corporation and water service institute. The organization has smooth
relation with the three organizations Telecom, Electric Corporation and water service institute.
The organization controlled by central administrator and managed by its own manager. Currently
the three organization information system process tasks in the form of document based
applications or traditional file systems. The current system of recording of bill system, financial
system, technical system and human resource management information has been formatted in
manual based.
1
1.2 Introduction about the project

We are trying to do the system which can solve all the problems within the current billing system
which held due to the manual system. We have considered all the problems within the system to
come on solution. We realized all the problems in the system, we viewed solutions to those
problems and we collected data in many ways about the existing system, we also used many
methodologies to get facts about the system. The main purposes of this project is aimed at
developing a system which reduces work burden of employees of the organization and for
customer use properly their time, resource ,cost and etc. Some times in manual process there is a
possibility to get errors. To overcome these difficulties we are proposed to develop web based
billing system. This will minimize labor force and the time required. In this the employees in the
organization submit the bills to their customer. The bills could have various types and also
various amounts. The bill will pass through a workflow process and the owner of the bill can
view the status of the bill at any time.
1.3. Statement of the problem
Many problems that exist in Dilla town billing system to finish their works properly and the
organization are currently facing challenging problems like:-
 It is time consuming process for customer.

 The present system is very less secure the mechanism of data handling is unsecured.
 It is unable to generate different kinds of report.
 It is having lots of manual works.
 Difficulty in conducting consistent reports.
 Unclear in handwriting and duplicating the sequence of bill number.
 It is less user-friendly.
 Absence of designed data base for the system.
 Reading the data is not accurate, because of it is boring for each owner.
Generally, this all initiate us to develop computerized based billing system to make the operation
easy, accuracy, consistent and time bounded.
2
1.4 Objective of the project

In this project we can specify the objective of the project as general objective and specific
objective.
1.4.1. General objectives

The general purpose of this project is to develop centralized Billing System for Dilla town.
1.4.2. Specific objective

Here are some specific objectives that would together help us achieve the overall the project as
follows:
 Study the existing system and find out the problem.

 Find the solution for the problem found in existing system.
 Design and build a particular model of this proposed system.
 To Develop and to implement the new billing system for Dilla town.
 Deploy the system and test it till it fits to the needs of the organization.
1.5 Scope and Limitation
1.5.1 Scope of the project

The scope of this project is developing web based system for Dilla town of water billing, electric
billing and telecom billing system for the office from adding customer to the system to collecting
revenue and particularly focuses as follow:
 Generating reports of bill.

 Setting privilege for employee.
 Create new user Account.
 Customer registration.
 View database for each organization
 Pay money for bill.
 Check payment of customer.
3
1.5.2 Limitation of the project

Since the system need some media to conduct transaction in this project every transaction will be
passed via internet. The other limitation of the project is
 Our system doesn’t support other bank account which is only included Commercial
Bank of Ethiopia (CBE) account with balance.
 The system does not support sending emails to different users.
1.6 Methodology
1.6.1 Data gathering methodology

1.6.1.1 Data Source
Existing Document
Document exploration is the process of going through a number of literature works that have
been conducted by other authors and organizations or researchers to review their thoughts, ideas,
and opinions towards a particular subject. In general, what they have achieved with their
previous work. During the analysis of documents, we give a special consideration to those
documents which can bring more features to the project.
1.6.1.2 Fact-finding Techniques
Interview:
We interviewed some of the employees about their existing system functionality, their problems
and background.
 To develop a deeper understanding of the data resources used by the system.

 To know what the current level of system usage by the office.
Observations:
It is observed `that present manual system has lot of functionalities which can overcome by
proposed system such as time, manpower, readiness of customer details etc.
4
Questionnaires:
The questionnaires will contain predefined questions that will help us to gather important
information and gives us some perspective from different angle. It will be spread to customers,
stakeholders and Bill staff members and managers. This will help us to know more information
about how much they want the system and in which way did they want the system to be
designed. It can be in terms of security and charge rate etc.
1.6.2. Design methodology
The data analysis model applied in this project is an object-oriented approach, Object oriented
method is selected because of the reusability of code by creating a common class for the different
modules it is possible to access the common attributes of the modules but it is not possible in
structural approach. In addition, object-oriented is latest approach nowadays & it has a large
acceptance. For designing purposes an object-oriented designing will be applied in this project
because it is easy to maintain if any error is occurred.
Regarding implementation, Hypertext Preprocessor (PHP) programming language will be

selected for this project since it can be dynamically changed. The system development model to
be used in this project is Component Based Model for the reasons that, component based model;
 Uses object-oriented paradigms.

 Classes are considered as component or module and combination of the components
will give us our web based system software.
 It is fast and widely used model due to reusability of codes.
1.6.3. Implementation methodology
Hardware
Different hardware’s will be used to develop our project.
5
Computer: - computer is a machine capable of doing many things. We use it to type on it

and install all software and programming language. All tasks are done on computer.
 Highest processor speed and latest CPU.

 8GB RAM.
 Hard disc 500 GB.
 Flash Disk and CD: - used for the movement of data from one machine to
another. We use both of them when we move our data from one machine to
another.
Software
 Microsoft office word:-It is very useful because it takes less time to write and
format the text, communicative effectively smart diagram and chart tools, quickly
assemble document. By looking its useful properties we use Microsoft office word
to type our project work to get all the above benefits of it.
 WampServer: - software used to develop php database. To create our php database
implementation WampServer is very important. It’s a development server for php
projects.
 Edraw Max: To develop the Unified Model Language (UML) diagrams we use this
software.
1.6.4 Testing methodology

Before directly deploying this system the team will perform different testing for its functionality
and meeting customers need. First the team tests each unit at each phase. So, if a problem is
encountered it will immediately fixed. Second the team will perform an integration testing to
check whether the system meets all the functional requirements, thirdly functional testing are
performed, higher level tests are used for System will be tested using the following system
testing procedures.
Unit testing
6
This is the most basic testing mechanism at the developer level. This covers very narrow and
well defined scope. We isolate the code from any outside interaction or any dependency on any
module. Then the testing focus on very small unit of functionality. They provide a simple way to
check smallest units of code and prove that units can work perfectly in isolation. However, we
need to check further that when these units are combined they work in a cohesive manner which
leads us to further types of tests.
Integration testing
Integration Test forms the next class of tests at the developer level. They provide a mechanism to
test the interoperation of smaller units. So we are going to use these testing methodology to
check whether the units are working together to achieve the project goal.
Functional Tests
After the integration tests are performed, higher level tests are used. Functional tests check for
the correctness of the output with respect to the input defined in the specification. Not much
emphasis is given on the intermediate values but more focus is given on the final output
delivered
Alpha testing
In this testing method, the system will tested by giving the correct input. It is tested by a
customer at the developer Site.
Beta testing
In this testing method, team will force the system to be tested for incorrect data input. The
System will be tested by the customer at their actual work place.
If any failures occurred while testing the system in all the above testing methods, the team will
take immediate correction beginning where this fault occurred before jumping to next work so
7
that it will meet the goal. If all the above testing methods are carried out and find to be valid the
system will directly deployed.
1.6.5. Development environment and programming tool

In this project the team will use object oriented system development methodology (OOSD) and it
has two phases.
1.6.5.1. Object Oriented Analysis (OOA)

During this phase the team used to model the function of the system (use case modeling), find
and identify the business objects, organize the objects and identify the relationship between them
and finally model the behavior of the objects.
1.6.5.2. Object Oriented Design (OOD)

During this phase the team will use rational rose software to refine the use case model, and to
reflect the implantation environment, model object interactions and behavior that support the use
case scenario and finally update object model to reflect the implementation environment.
We used Object Oriented System Analysis Development (OOSAD) because of the following
important features:-
Increase reusability:
The object oriented provides opportunities for reuse through the concepts of inheritance,
polymorphism, encapsulation and modularity.
Increased extensibility:
When we want to add new feature to the system we don’t need to change the entire application
class.
Improved quality:
8
Quality of our system must be on time, on budget and meet the expectation of the users of our
system improved quality comes from increasing participation of users in the system
development.
Financial benefits:
Reusability, extensibility and improved quality are all the financial benefits, because they led to
the business benefits of the object- oriented from the point of view of the users, the real benefits
are if we can build system faster and cheaper.
Reduced maintenance cost:
Software organizations currently spend significant resources maintain operating system so the
object oriented development methods help us to overcome these problems.
1.6.5.3 Programming tool

This can be divided into two phase’s system development tools (programming tools) and system
design and analysis tools (documentation tools).
1.6.5.3.1 System Design and Analysis Tools

We will try to make clear, consistent and easily understandable design as much as possible.
The designed application should fulfill the functional and non- functional requirement. This is
done by frequently testing the system during design stage. We try to use all fundamental tools of
software design and development. The tools which we are used during development of this
project are listed as follows:
 Use case diagram.

 Activity diagram.
 Sequence diagram.
9
 Class diagram.
1.6.5.3.2 System Development Tools
In order to develop the new system, our team identifies programing languages, database
management software, editors as tools to be used in the development process as well as software
and hardware tools.
 HTML/DHTML/XML: -Client side coding.

 JavaScript:-Client side scripting.
 Php: - Server-side scripting.
 MySQL: - we used My Structural Query Language (MySQL) to design the data base.
 XAMPP: - we used Cross-Platform (X), Apache (A), MySQL (M), PHP (P) and Perl
(P). (XAMP) as a server.
 IE 5.5/6.0/7.0, Mozilla Firefox 3.0.:- Browsers.
1.7. Feasibility study
While doing this project, it is fair to see some conditions with regard to cost, clients (end users)
and also about the system developer.
1.7.1 Technical Feasibility

The goal of technical feasibility is to understand the organization ability to construct the
proposed system. Our system is technically feasible. Because, centralized Billing system of Dilla
town has its own computer printer and software such as Structural Query Language (SQL)
-server and Php Designer that are needed for the new system. Therefore based on the above
different considerations the project is Feasible to be conducted using the new system and Billing
System office of Dilla town is benefitted if the new system is adopted fully.
1.7.2 Operational Feasibility
When the system is installed and become operational the company personnel or who is supposed
to manipulate this system shall trained how to work with the new system. Therefore the proposed
system or the new system is operationally feasible because:
 The new system fits with the existing operational system.
10
 Satisfy the user need or requirement.

 Provide the customer and workers with timely, accurately, reliable and flexible and
usefully formatted information.
1.7.3 Economic feasibility
Economic feasibility consists of tangible and intangible feasibility which are described as
follows.
Tangible:
 Reduce the amount of resource required in office.
 Reduce data redundancy storing in the database.
 Improve office efficiency, speed and flexibility.
1.8 Benefit of the project

Since the system is being automated to avoid extreme problems of recording manually form, this
increase satisfaction for employee than they get can before. The main advantage of this project is
going to be computerized in order to reduce resources used for manual operation and it will
save time that can be spent during manual system. The benefits that we have pointed out in
this system development are:
 Increased speed of activity.

 Increased flexibility.
 Easily access customers’ information from organized database.
 It gives fair distribution of resources.
 Easy and quick to use.
 Increased authentication, and more timely information.
 Ensure data accuracy’s.
 Better service.
 User friendliness and interactive.
 Improves efficiency of the system accessibility of resource.
 Save their time and Reduce work load.
11
1.9. Project schedule (using Gantt chart)
The proposed system can be implemented in an acceptable timeframe given.
Table 1 . Task and Schedule.
Centralized Billing Duration in month

System
ID Task name
December January February March April May June
1 Phase One: System
development proposal
2 Phase Two:
Documentation
Phase Three: project
3 design and
methodology
Data Collection
3.1
System analysis
3.2 And design
Phase Four: coding
4 and implementation
Finished work s Unfinished work
CHAPTER 2
EXISTING SYSTEM
2.1. Introduction of Existing System
The existing system of the billing system for telecom, water and electric is working separately
means in different places. Whatever be the process involved in the system is working through
computerized way. There are a lot of complexities involved in the system. When any customer
12
takes new interaction with the system then separate files are maintained. Updating of data is very
tedious job. It is not easy to do several administrative works like managing rates of calls,
addition or modification of metered calls & customer entries. The existing system required
different data about customer name, sex, nationalities, Keble, house number which are customers
give to the employee. In this system administrators accept the request of the customer from
employee and the administrator sends customer request to the central administrator and the
central administrator provide registration number of customer to the administrator then the
administrator gives the bill number to the customer.
2.2. Description of existing system

Current system of billing system for telecom, water and electric services are manual. From this
system we take some forms as they are. The forms generated in the existing system are in the
forms of forms and files. The system displays all the bill details such as bill no, name and price
etc. The existing system use file and forms that is used to perform the business rules, describe the
operations, definitions and constraints that apply and deployment of system.
Forms: - The reports generated in the existing system that contains all information filled by the
costumer.
Files: - The collection of information about each costumer who involves in the billing system.
These all reports kept in offices of the each service provider.
2.3. Limitation of the existing system

There are a lot of limitation in the existing system as compared to the proposed system. These
limitation can be seen from the following perspectives like performance, information, economic,
control and security, efficiency and services given by the existing system to the users, by using
the
Framework as follow: -
2.3.1 Performance (Response time)

Since the existing system is not centralized, it takes long response time. For example when one
costumer went to for his bill it takes much longer time to get and search since it’s in different
13
places. The acceptable response time for a particular task is large. But in the proposed system
concurrency limitation can be solved by the new system at a time.
2.3.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate)

 Receive the incorrect/redundant costumer list.
 To fill incorrect name and id.
 One costumer may be asked twice per month because of if the data is loosed. As a result
there will be conflict b/n costumer and workers.
2.3.3 Security and Controls

In the existing system security and control is somewhat worried about. It is difficult to control
the system because there is no privilege in data accessing. Here the necessary reports may not
generate at exact time so it may occur security violence. The system shouldn’t provide sufficient
protection for access and manipulation of the records associated with the system. So it is not
easily protected and used properly the resource.
2.3.4 Efficiency
Most of the activities are prone to wastage of resources like man power, time etc. to produce the
corresponding outputs. This makes the current system inefficient while utilizing resources. There
should be a mechanism that reduce wastage of resources and that make the system to be
efficient. As a result the new system will reduce wastage of resources and make it efficient.
The existing system has less efficiency than the proposed system. The existing system has
concurrency control problems i.e. more number of users. Data management facilities are limited
and the reporting schemes are not according to the specific needs of the users.
2.4 Model of Existing System

System modeling is aimed to present the system model at a level that can be directly traced to the
specific system objectives along with providing more detailed data, functional, and non-
functional requirements. It will verify that the current model meets all of the explicit
requirements contained in the system model as well as the implicit requirements desired by the
14
user. It is performed by identifying actors and use cases. Under this topic we use different kinds
of UML diagrams to model the functionality, structure and Sequence of activities of the system.
2.4.1 Actor
In the existing system there are numbers of actor each having their own Responsibility?
Customer: - someone who wants to access the service.
Administrator: - a special user of the system who can setup access right for other users.
Bill staff/Employee:-is a person who checks whether the customer reserve ticket or not.
2.4.2 Essential use -case
Figure 1. Essential use case Telecom.
15
Figure 2. Essential use case of water service.
Figure 3 . Essential use case of Electric service
16
2.5 Business rules

The main business rules or principles of the existing system are:-
 Anyone who signs the bill form must be the member of the service.
 Customers will pay money for what they use per month. And no payment difference for
the same service.
 Customers should get the bill for what they are paying.
 Some gap is given for a costumer to pay within a given day. If they didn´t pay within a
given day they punished.
 Customer should be ask the previous month bill to pay for the next month.
17
CHAPTER 3
PROPOSED SYSTEM
3.1 Overview of the proposed system
The proposed system is designed to eliminate all the drawbacks of the existing billing system.
The system shall be responsible for create new user account, assign customer bill account, make
accessible for a user, pay money for bill and check payment of customer. All these features
include the ability to add user, updating customer information, search customer information,
delete existing user from the system, view database for each organization, view comment of
customer and retrieve through search bill results.
The system have provided as the following below point.
 The important thing is to make works easy.

 It is centralized billing system process.
 The proposed system stores all the information about billing at one center place for all on
the database other than store separately.
 Centralized billing system of the system must fulfill the requirement of giving effective
services in terms of speed, security, accuracy, response time, efficiency, reduce man
power and time, etc.
 Security: -since the system requires verification of login form, sensitive
information will not be accessed or modified by unauthorized users.
 Efficiency: -since the system record each and every customer’s information on the
data base, retrieval of customer’s files from the database at any time is a very easy
process.
 Response time: -it takes short time to access the system.
 Accuracy: - Receive the correct/remove redundant costumer list such as customer
name and customer id because to avoiding conflict between employee and user.
 Speed: - it provides save their time, reduce work load, easily access customer
information from database and quick access the system.
18
3.2 Requirements of the Proposed System
3.2.1 Functional Requirements

A functional requirement specifies what the proposed system should do. The area bound of our
project focuses mainly on functional aspects of Water billing, Electric billing and Telecom
billing system for the office from adding customer to the system to collecting revenue and
particularly focuses on:
 Create new user Account.

 Updating customer information.
 Delete Existing User from the system.
 View comment of customer.
 Search customer information.
 Generate reports of bill.
 View database for each organization.
 Pay money for bill.
 Check payment of customer.
 Search Bill.
3.2.2 Non-Functional Requirements

A non-functional requirement specifies how the new system should perform.it is a statement of
how a system must perform; it is a constraint upon the systems behavior. Non-functional
requirements specify all the remaining requirements not covered by the functional requirements.
They specify criteria that judge the operation of a system, rather than specific behaviors. Non-
functional requirements specify the new system’s ‘quality characteristics’ or ‘quality attributes’.
Potentially many different stakeholders have an interest in getting the non-functional
requirements right. This is because for many large systems the people buying the system are
completely different from those who are going to use it customers and users.
19
Performance
Performance requirements define acceptable response times for system functionality. Response
time for centralized billing system should be faster than the existing system. Response time
refers to the waiting time while the system accesses, queries and retrieves the information from
the databases.
 Response time of the system will not take long time. This means a customer find those of
three organization at the time, at the same place to get serves in short time.
 The system should support many users at a time.
User Interface
 The window format and the forms prepared for the information are easy to user they can
easily understand.
 The system shall be design according to standards and the system shall replace existing
system.
Backup and Recovery
 If the connection between the user and the system is loss the system will automatically
save the filled information and the remaining can enable by the administrator by
contacting the costumer using phone.
 To recover a data we will have a copy of the original data in another place.
3.2.3 System Requirement

A system requirement specifies a function that a new system or component must be able to
perform. For example functional requirement of our system is must assign customer bill account
and make accessible for a user.
The main system requirement that used to handle are observable tasks or processes that must be
performed by the system.
 Make accessible the interface to customer and user

 Assign customer easily, accurately and quickly.
Solve the problems that will be occurring around bill system.
20
Performance requirements
 Our system will capable to increase total throughput speed under an increased load when
resources are added.
 Enable the administrator to create, modify, or even to delete his/her account if it is
necessary.
 The system can generate information and forms for user to access Friendly.
Process requirements
 There will be efficient storage and easy accessibility and user must have his/her own
account.
 Cancel or modify his/her by asking the administrator that they wants to cancel to be a
member of the service.
 During registration each costumer should fill the appropriate information in the specified
place.
Input related requirements
 There will be accurate and flexible input mechanisms.

 The input form must include name, date and customer login detail and others.
 Collecting the information of the costumer who is going access service for Water,
Electric and Telecom. The administrator must enter the password so that access is given
only to him to view the detail.
 The costumer pay at administrator place then the administrator send for all company
means Water, Electric, and Telecom.
Output related requirements
Since the input is effective the output is also effective. There will be accurate display of
customer reports in accordance with the query process accessibility is possible for whom who
has an account and no one can view information unless matched successfully.
Storage related requirements
There will be efficient storage and the entire processed system can stored in the database.
21
3.3 User Interface Specification and Description
The user interface found in the central billing system are as follows:-
User Interface: - Users are able to view the home page of the billing-cart system, browse the
different categories and add any number of customer from the categories of Water service,
Electric service and Telecom service view information about each service, pay online, pay in
cash, add money, generate report, check payment and check out the service by completing the
required information in the order form. The user interface will be simple and consistent, using
terminology commonly understood by the indented users of the system. The system will
have a simple interface, consistent with enterprise standard interface. User testing will be used
to ensure the user interface is clear/simple, commonly understood vocabulary, intuitive to
use without training.
User interface design
Figure 4. User interface specification.
22
In user interface our main aim is to maintain and create the “ease of understanding” and “user
friendly interface” for the users. In doing so, we are designing the following rules
 The user selectable options are always accessible on the left and top.
 The user billing cart is always on the left side of the screen.
 The main screen, which will always be on the right, will contain all the selected services.
 The user should be able to check out at any time no matter where they are on the site.
 Each web page should have the number of service selected.
 Each page will have a link for the home page and search options.
 Every Page always shows the company logo.
 Every service listed anywhere on the webpage’s.
23
CHAPTER 4
SYSTEM MODELING
4.1 Introduction
In this project, we used an object oriented System development methodology which incorporates
two principal phases. In this chapter, what will we do is the object oriented analysis (OOA) in
this phase we can identify the relationship between objects and the interaction between each
object. During Object Oriented Analysis the following major activities are performed.
4.2 Use case diagrams

A use case diagram at its simplest is a representation of a user's interaction with the system that
shows the relationship between the user and the different use cases in which the user is involved.
A use case diagram can identify the different types of users of a system and the different use
cases and will often be accompanied by other types of diagrams as well.
Figure 5. Use case diagram.
24
4.2.1 Use case description

Log in
Table 2. Use case for log in.
Actors Administrator ,Employee, costumer

Use case name Login
Use case Id 1
Description Log in the system
Pre-condition The costumer has been registered at centralized
Post condition The costumer has been authorized.
Basic course of Actor Action System Response
Action Step1: The costumer wants to log in Step2: The System display
costumer log in form
Step3: The costumer enter Username and Step4: The system validates
password whether the username and
password submitted is
correct(already in the data base)
Step5: The system display the

costumer account page
Step:6 The use case ends
Alternative 1. The user enter wrong username and password

course of action Step 4. 1 The system indicates the costumer information invalid
Step 4. 2 The use case continues Step 3 of the basic course of action
Update account
25
Table 3. Use case for update account
Actor Administrator
Use case ID 2
Use case name Update account
Description This use case allows To update costumer account
Pre-condition The administrator wants update employee and customer
information
Post condition The administrator have information that will be updated
Basic course of Actor Action System Response
Step1: the administrator can Step2: The system Displays
Action
request to update the user information update
costumer information and page
other information in the Step4: The system validates
Database. whether the information
Step3: The administrator submitted is correct
enter the necessary new Step5: The system displays
information. confirmation page and save
the updated information.
Step6:The use case ends
Alternative course of action 02. The input information invalid
Step 4.1 The system indicates the costumer information
invalid
Step 4.2 The use case continues Step 3 of the basic course of
action
Delete account
Table 4 Use case for delete account.
26
Actors Administrator
Use case Id 3
Use case name Delete account
Description This use case describe the canceling of existing account
Pre-condition In case the customer doesn’t pay the required money for what
he/she used. But there must be the created account
Post condition The account will be deleted automatically
Basic course of Action Actor Action System Response
Step1: The administrator Step2:The system Displays
wants to cancel the created delete account
account Step4: The system validates
Step3: Enters the account whether the information
number submitted is correct or exist
Step5: Selects the "Process Step6: The message "Account

Delete" option. has been deleted
successfully" is also
displayed
Alternative course of action 03. The input reservation number is invalid
Step 4. 1 The system indicates the user information invalid
Step 4. 2 The use case continues Step 3 of the basic course of
action
Check payment
Table 5 Use case for check payment.
Actor Employee
Use case ID 4
Use case name Check payment
27
Description This use case gives information about the payment.

Pre-condition The payment will be per month
Post condition The customer gets bill from employee.
Step1: The user wants to pay Step2:The system Displays
Step3:The user enters account payment Page
and amount of birr Step4: The system checks
whether the payment is
enough or not
Step5: The message "transfer
Successfully” is also
displayed.
Alternative course of action 04. If not enough birr or wrong id number
Step 5. 1 The system indicates invalid entry
Step 5. 2 The use case continues Step 3
Create Account
Table 6. Use case for create Account
Actor Administrator, employee

Use case Id 5
Use case name Create Account
Description This use case gives information about account creation that
means administrator will create account for employee and the
employee will create account for costumer.
Post condition After registration all customer starts using the service
28
what they have Requested

Step1: The customer wants to Step2: the system displays the
register registration form
Step3: The Employee asks all Step4: The system checks
the necessary information whether the all the
from the user information is filled or not
Step5: Click the "Register"
Step6: The message "Register

option successfully
generated” is also displayed
Alternative course of action 05. The generated report is invalid
action
Generate report
Table 7. Use case for generate report.
Actor Employee
Use case ID 6
Use case name Generate report
Description This use case gives information about all what is done with
respect to the service
Pre-condition In case the employee want to generate report on that day or
for the week
Post condition The necessary report generated and saved to the database.
Basic course of action Actor Action System Response
Step1: The employee wants Step2:The system Displays
29
to generate report generate report page

Step3:Manager enters the Step4: The system checks
generate report whether the report is
corrector not
Step5: Selects the "Process of
report generation” option
Step6: The message "report
successfully generated” is
also displayed
Alternative 06. The generated report is invalid

action
Pay money
Table 8. Use case for payment.
Actor Customer
Use case Id 7
Use case name Pay money
Description This use case gives information about paying money for
employee usage
Pre-condition In case the employee have an access to the service
Post condition The Customer will pay for what they have used per month
Step1: The costumer wants to Step2: The system Displays
pay the Step4: The system checks
Step3: The employee will fill whether the user to
all the required information information are filled
Step5: Selects the "pay" correctly or not
30
option. Step6: The message "pay

successfully” is also
displayed Step7: The use case
end.
Alternative course of action 07. else the above is invalid

Step 8. 1The system indicates the user information invalid
Step 8. 2The use case continues Step 3 of the basic course of
action login the bank page
Prepare bill
Table 9. Use case for prepare bill.
Actor Employee
Use case ID 8
Use case name Prepare bill
Description This use case gives information about prepare a bill.
Pre-condition The user must ask the bill.
Post condition The bill will be given to each individual in the form of
message for what they have used. The user have to search to
get the bill information
Basic course of action Actor Action System Response
Step1: The employee wants Step2: The system Displays
to prepare bill for the user the form
Step3: The employee will fill Step4: The system will say
all the information “you have prepare the bill
correctly
31
Alternative course of action 08. if all the above is invalid

Step 9. 2 The use case continues Step 3.
View report
Table 10. Use case for view report.
Actor Administrator
Use case ID 9
Use case name View report
Description Here the use case will help the administrator to display the
report
Pre-condition In case the employee want to generate report on that day Or
for the week
Post condition The necessary report generated and saved to the database.
Step1: The administrator Step 2: The system view
want to view their own report page.
report. Step 4: The system check
Step 3: Then the whether the customer ID is
administrator enters customer correct or not.
ID. Step5: The user will search
the Report.
Step 6: The use case ends.
Alternative course of action 09 The report is invalid
32
Step12. 1 The system indicates the user information invalid

Step12. 2 The use case continues Step3 of the basic course of
action
4.3 Sequence diagram

A Sequence diagram is an interaction diagram that shows how processes operate with one
another and in what order. It is a construct of a Message Sequence Chart. A sequence diagram
shows object interactions arranged in time sequence. It depicts the objects and classes involved
in the scenario and the sequence of messages exchanged between the objects needed to carry out
the functionality of the scenario. Sequence diagrams are typically associated with use case
realizations in the Logical View of the system under development. Sequence diagrams are
sometimes called event diagrams or event scenarios.
Login
33
Figure 6. Sequence diagram for login.
Create account
34
Figure 7. Sequence diagram for create account.
Update account
35
Figure 8. Sequence diagram for update account.
Delete account
36
Figure 9.Sequence diagram for delete account
Check payment
37
Figure 10. Sequence diagram for check payment.
Prepare bill
38
Figure 11. Sequence diagram for prepare bill.
Generate report
39
Figure 12. Sequence diagram for generate report
Payment
40
Figure 13.Sequence diagram for payment
View report
41
Figure 14. Sequence diagram for view report.
42
4.4 Activity Diagram

Activity diagrams are used to document the logic of a single operation /methods, a single use
case, or the flow of logic of a business operation. In many ways, activity diagrams are the
object_ oriented equivalent of flow charts and data flow diagrams from Structure.
Login
Figure 15. Activity diagram for login
43
Create account
Figure 16. Activity diagram for create account.
44
Update account
Figure 17. Activity diagram for update account.
45
Delete account
Figure 18. Activity diagram for delete account.

Generate report
Figure 19. Activity diagram for generate report

46
Prepare bill
Figure 20. Activity diagram for prepare bill.
47
Pay money
Figure 21. Activity diagram for pay money.
48
4.5 Class Diagram
The class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing and documenting different aspects of a
system but also for constructing executable code of the software application. The class diagram
describes the attributes and operations of a class and also the constraints imposed on the system.
The classes diagrams are widely used in the modeling of object oriented systems because they
are the only UML diagrams which can be mapped directly with object oriented languages. The
class diagram shows a collection of classes, interfaces, associations, collaborations and
constraints. It is also known as a structural diagram
Figure 22. Class Diagram.
49
4.6 Database specification

Database design is the process of producing a detailed data model of a database. This logical data
model contains all the needed logical and physical design choices and physical storage
parameters needed to generate a design in a data definition language, which can then be used to
create a database. A fully attributed data model contains detailed attributes for each entity.
The term database design can be used to describe many different parts of the design of an overall
database system. Principally, and most correctly, it can be thought of as the logical design of the
base data structures used to store the data. In the relational model these are the tables and views.
In an object database the entities and relationships map directly to object classes and named
relationships.
The process of doing database design generally consists of a number of steps which will be
carried out by the database designer. Usually, the designer must:
 Determine the relationships between the different data elements.

 Super impose (place one thing over another, typically so that both are evident) a logical
structure upon the data on the basis of these relationships.
Database of Bank
Table 11. Table of bank.
Column name Data type Primary key Foreign key Null value
Id Int(12)  No
First name Varchar(20) No
Last name Varchar(20) No
Branch Varchar(34) No
Accno Int(23)  No
Amount birr Int(20) No
Date Date No
50
Database of Water service

Table 12. Table of Water service
CID Int(11)  No

Fname Varchar(50) Yes

Lname Varchar(50) No
Address Varchar(50) No
Phone Int(12) Yes
House no Int(10) Yes
Amount of bill Int(50) No
Date Date No
Database of Telecom service
Table 13. Table of Telecom service
CID Int(11)   No
Phone Int(12) Yes
House no Int(10) Yes
Date Date No
Database of Electricity service
Table 14.Table of Electricity service.
51
CID Int(11)   No
Phone Int(12) Yes
House no Int(10) No
Date Date No
Database of bill report
Table 15. Table of bill report.
Bill no Int(11)  No
Date Varchar(23) No
Fname Varchar(23) No
Amount of birr Int(35) No
Phone_no Varchar(34) No
Service type Varchar(34) No
Report Varchar(30) No
Service_no Int(10) No
User name Varchar(30) No
52
4.6.1 E-R Diagram
Figure 23. E-R Diagram.
53
CHAPTER FIVE
SYSTEM DESIGN
5.1 Introduction
System design is the transformation of the analysis model into a system design model. During
system design, developers define the design goals of the project and decompose the system into
smaller subsystems that can be realized by individual teams. The result of system design is a
model that includes a clear description of each of these strategies, subsystem decomposition,
component diagram and deployment diagram representing the hardware/software mapping of the
system.
5.1.1. System Overview

This chapter mainly concerned with the design part of all about the billing system. In this section
we will see the different types of class type architectures, such as user interface layer, process
control layer, business /domain layer, persistent layer, and system layer and also different types
of system modeling techniques that are used for the implementation types of the system such as
class modeling, component modeling, deployment modeling and also some system design
techniques such as user interface designing are also to be covered in this design chapter.
5.1.2. Design Goal

In our system development process system design part is very important so as to make the
implementation of the proposed system very easy. The different types of system modeling
techniques that are used to make easy the implementation of the system such as deployment and
component diagram are show in detail. Not only the system modeling techniques but also
some system design techniques such as system decomposition design are cover in detail
in this phase.
Some of the design goals are:-
Security- Since the system hold an important information (data), the system require strong
security features to protect that valuable information i.e. not allow other users or unauthorized
users to access data that has no the right to access it.
54
Performance: - They should have a fast response time (real time) with maximum throughput.
In the case of the timetabling subsystem, the system should be more reliable in order to satisfy
the constraints than fast response time.
Maintenance:-The system should be easily extensible to add new functionalities at a later stage.
It should also be easily modifiable to make changes to the features and functionalities.
Fault Tolerance:-The system should be able to give response (error message) When the user
enter incorrect input. This recommends the user to enter correct input.
Throughput:-Since centralized billing system has web application it is able to perform many
tasks at any time.
Robustness: - The system has the ability to survive wrong applicant inputs. Besides this end
applicant that use centralized billing system site have limited access regarding info about
applicant (like name phone no, email address).
Modifiability:-The proposed system able to handle applicant data based on selected service
center such as water service, electric serves and telecom service.
Usability: - centralized billing system provide easy user friendly interface for users of the
systems. It also provides help menu which gives brief description how to use the system so that
user can be able to use it easily.
5.1.3. Architecture of the System

Architecture of the System provides a strategy for layering the classes of the system to distribute
the functionality of the software among classes. Furthermore, architectures of the system provide
guidance as to what other types of classes a given type of class will interact with, and how that
interaction will occur. This increases the extensibility, maintainability, and portability of the
systems.
55
Interface: This layer wraps access to the logic of our system. This layer consists of interface
class: user interface (UI) classes that provide people access to our system.
Domain: This layer implements the concepts pertinent to our business domain, focusing on the
data aspects of the business objects, plus behaviors specific to individual objects.
Process (controller): The process layer implements business logic that involves collaborating
with several domain classes or even other process classes.
Persistence: Layers encapsulate the capability to store, retrieve, and delete objects/data
permanently without revealing details of the underlying storage technology.
System layer: Classes provide operating-system-specific functionality for your applications,

isolating your software from the operating system (OS) by wrapping OS-specific features,
increasing the portability of your application
Figure 24 Architecture of the system
56
5.2 System Design.

System Design phase is process of describing, organizing, and structuring system components at
architectural design level and detailed design level. Design converts functional models from
analysis into models that helps to represent the solution for the problem. In system
designing process we can use structured or object oriented approaches. In the case of on Dilla
town centralized billing system our system design the gap between the system specification
produced during requirement elicitation and analysis which is concentrated on the purpose
and the functionality of the Dilla town centralized billing system.
In the design phase of the Dilla town centralized billing system, system decomposition,
component modeling, database design ,class mapping, deployment diagram and the exact
architecture of the proposed system which is the user interface prototyping will be showed in
detail is showed in detail.
5.2.1 Subsystem decomposition

Subsystem decompositions help to reduce the complexity of the system. Subsystem is the
collection of classes, associations, operations, events and constraints that are closely interrelated
with each other.
Actor of centralized billing system are administrator, employee and customer
Admin user account

 Control account
 Manage account
 Create account ()
 Delete account ()
 Update account ()
 View feedback
 View report
 Change password
57
Employee use account
 Pay in cash.
 Prepare bill.
 Generate report.
 Check payment.
 Change password.
 Post notification.
Customer use account
 Pay online
 Transfer money
 Feedback
 View Notification
 Change password
Figure 25 Subsystem diagram
58
5.2.2 Component diagram.

The component diagram illustrates the software components to build the system. Components
are modeled as rectangles with two smaller rectangles jutting out from the left hand side.
Components have dependencies on the interface of other components. Component diagrams can
show how various components are structurally related to one another in a given system. These
charts are capable of showing a high level of complexity and can be adapted to a variety of uses.
The component diagram below shows relationships for a centralized billing system.
Figure 26 Component modeling diagram
59
5.2.3 Hardware and Software mapping.

The Hardware/Software Mapping addresses dependencies and distribution issues of UML
components during system design.
Selection of platform (hardware configuration and software platform)
 Processor, memory, network and input/output.

 OS platform (window), DB (MYSQL), communication protocol (http).
Subsystem mapped on the chosen hardware and software:-
 Mapping to processor:- parallel processing

 Mapping to computer:- client/server and distributed computing
Figure 27 Hardware-software mapping.
60
5.2.4 Deployment Diagram.

Deployment diagram depicts static view of the run time configuration of processing nodes and
the components that run on those nodes. Deployment diagram also shows the hardware for the
system, the software that is installing on that hardware and the middleware used to connect the
disparate machines to one another. A deployment diagram in the unified modeling language
models the physical deployment of artifact on nodes. The nodes appear as boxes, and the
artifacts allocated to each node appear as rectangles within the boxes. Nodes may have sub
nodes, which appear as nested boxes. A single node in a deployment diagram may conceptually
represent multiple physical nodes, such as a cluster of database servers.
Figure 28 Deployment diagram.
61
5.3 Detailed Design.
5.3.1 Package diagram.

Package diagram shows the dependencies between different packages in a system and used to
group elements that are semantically related and might change together. It is a general purpose
mechanism to organize elements into groups to provide better structure for system model.
Package diagrams are simple variations on class diagrams to show packages and their
relationships. Package diagram shows the arrangement and organization of model elements in
middle to large scale project. It can show both structures and dependencies between sub-systems
or modules.
Figure 29 Package diagram
62
5.3.2 Collaboration diagram.

Collaboration diagram represent a combination of information taken from class, sequence, and
use case diagrams describing both static structure and dynamic behavior of a system.
Collaboration diagram show the message flow between objects in an object oriented (OO)
application, and also imply the basic associations or relationships between classes. The rectangle
represent the various objects involves that make up the application, and the line between the
classes represents the relationships (association, aggregation, composition, dependencies, or
inheritance).Use a collaboration diagram (collaboration diagram: An interaction diagram that
shows, for one system event described by one use case, how a group of objects collaborate with
one another.) to show relationships among object roles such as the set of messages exchanged
among the objects to achieve an operation or result.
Figure 30 collaboration diagrams for registration
63
Figure 31 Collaboration diagrams for view report
64
5.4 User Interface design

User interface design is the overall process of designing how a user will be able to interact with a
system. The goal of user interface design is to make the user's interaction as simple and efficient
as possible, in terms of accomplishing user goals.
User interfaces for home page
Figure 32 User interfaces for home page
65
User interfaces for Login page
Figure 33 User interfaces for Login page
66
User interface for Admin
Figure 34 User interfaces for Admin page
67
User interface for Employee page
Figure 35 User interfaces for Employee page
68
User interfaces for Customer page
Figure 36 User interfaces for Customer page
5.5 Access control and Security.

Access control and security describes the user model of the system in terms of access matrix. In
this system actors have access to different functionality and data to protect unauthorized access
we used data encryption and to secure the data, taking backup daily is considered as preferable.
In addition during user interaction we used session control mechanism to protect unauthorized
access.
Security:-We tested the security of our proposed system through login page are all users must
first login to perform operations and get services and also all user information’s are stored on
external database.
Authorize mechanism: - This mechanism worked by login form by checking the login form
with the login table.
69
CHAPTER SIX:
IMPLEMENTATION
6.1 Objective of implementation
Implementation refers to the coding of the all documents gathered starting from requirement
analysis to design phase. All documents, business logic, information gathered are designed into
the code so that the system will be implemented for the user to be used for the purpose it
developed. The chapter here describes about hardware and software acquisitions, user manual
preparation, installation process and algorithm and outputs. The functional system from the
design phase above is the key input to the implementation phase. The deliverable of the
implementation phase (the project) is the operational system that will enter the operation and
support stage of the system’s life cycle. Here is the sample code for each module.
6.2 Hardware and Software Acquisitions.

Hardware acquisition: The system is going to be implemented on the Dilla town billing system
for the three services. Since our system is web based for its deployment a web server is needed.
Software acquisition: The client side application is compatible with windows environment
For the System implementation the following software’s are used.
 PHP language
 Google chrome.
 Window 10 operating system.
 Edraw max.
 My SQL.
70
6.3 User Manual Preparation.

User manual preparation since the system is web based application everything important for the
user would be explained and implemented while preparation of short training document when the
system is deployed. And also notify the user whether the teams prepare to give training
6.4 Algorithm and Outputs
6.4.1 Sample Code.

Pay online code
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"

"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"><html
xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"<head> <title>DILLA TOWN
CENRALIZED BILLING SYSTEM</title>
</div></div><div id="menubar"><ul id="menu">
<li ><a href="customer.php"><font color="white">HOME</font></a></li>
<li><a href="logout1.php"><font color="white">logout</font></a></li>
</ul></div>
<div id="site_content">
<div class="sidebar_container" style="width: 244px">
<div class="sidebar">
<div class="sidebar_item">
<body bgcolor=#9494B8>

<hr><hr><font size="3"color ="green">

<?phpecho "<b>".date('l\, F jS\, Y ')."</b>";
71
72
?></font><br><hr><hr></body><img width="240" height="200"

src="customer/opqr/onlll.jpg"/>
<font size="5"color="green"><b></b></font>
<table bgcolor="#4b474"align ="center" id="table2"><tr><td>
<img img class="mySlides" width="225" height="150"src="customer/fgnm/mo

dolar.jpg"></td</tr><tr><td><img width="225"
height="100"src="customer/opqr/traaw.jpg"></td>
</tr></table><br><br><hr><hr><img width="215" src="Img/feln-crowd_2.png"/>
<hr></hr> <marquee direction="up"><p> </p></marquee></th>
</tr> </table> <p> </p><p> </p>
</div>
</div> </div>
<div id="content1" style="width: 792px">
<div class="content_item" style="height: 692px">
<Center>
<div style="width:932px; height:690px; position:relative; -webkit-border-

radius:5px; -moz-border-radius:5px; border-radius:25px; -webkit-box-shadow:0 0 18px
rgba(0,0,0,0.4);
-moz-box-shadow:0 0 18px rgba(0,0,0,0.4); box-shadow:0 0 18px rgba(0,0,0,0.4);

left: 0px; top: -23px; margin-left: auto; margin-right: auto; margin-bottom: 0;">
<form method='POST' action='pay.php' onsubmit='returnn formValidation()'

enctype="multipart/form-data">
<div style="background-color:#336699;border-radius:5px;font-family:Arial, Helvetica, sans-

serif; color:#000000; padding:5px;
height:22px;">
<div style="float:left;" ><img width="30" height="20"

src="Img/birr.jpg"/> <strong><font color="white" size="2px">
Search Customer payment !</font></strong></div>

73
<div style="float:right; margin-right:20px; background-color:#cccccc; width:25px; text-

align:center; border-radius:10px;
height:12px;">
<a href="employee.php" title="Close"><img src="img/close_icon.gif"></a></div>
</div>
<input type="hidden" name="role" id="name" value="<?php echo '4'; ?>" />
<table bgcolor="gray"align="left" style="margin-top:15px;box-shadow:1px 0px 0px black;

background-color: #00FFCC; width: 906px; height: 454px;" class="auto-style1">

<tr><td style="width: 591px" class="auto-style2"><font color=black>
Customer ID
<input type="text" name="search" value="" size='20%' id="txt_l" placeholder='ID'

pattern="\d{2,10}" required x-moz-errormessage="Please Enter your fname "
title="Please Enter your name code" style="width: 143px" >
</input> </td>
<td style="width: 1170px" class="auto-style2">Service Type:

<td style="width: 537px" class="auto-style3">
<h6>
74
<input style="background-color:#808000; height: 47px; width: 87px;"type='submit' class="auto-

style4" value="Search" name='submitMain' Onclick="return check(this.form);"/></h6>
</td></tr><tr><td><img width="730" height="392"

src="Img/mn.png"/></td></tr></form></center></div> </div </div></div></body></html>
6.5.2 Sample Results.
Figure 37 sample output of Pay online page
75
CHAPTER SEVEN:
TESTING
7.1 Introduction.
Testing: The process of executing a system with the intent of finding defects. It is the final step
of testing in which the entire system as a whole with all forms, code, and modules are tested. In
this procedure we have tested all the functionalities of the system. All errors in the forms,
functions, modules have been tested. Finally system testing ensures that the entire integrated
software system meets the desired requirements. It tests a configuration to ensure known and
predictable results. To the test whole system the team follows the following procedures.
7.2 Unit Testing and Result.

Unit testing is a software development process in which the smallest testable parts of an
application, called units, are individually and independently scrutinized for proper operation.
Purpose: to verify that the component/module functions properly.
Every module of the System is separately tested. The team tests every module by applying some
selection mechanism, through this mechanism every modules gets tested.
If an error occurs correction will be taken without affecting another module. We have tried to
test UI screens of our system that needs to verify screen elements that appears on the screen.
 Incorrect password and username
Figure 38 Unit testing.
76
7.3 Integrated Testing.
In this testing part, all the modules will be combined together and tested it for its fitness with
each other and with the systems functionality. If error occurs in combining them, the module
with problem will be identified and recombined. Both units testing and integrated testing are
performed by all team members at the work place.
Purpose:
 To ensure that code is implemented and designed properly.
 To take unit tested modules and build a program structure that has been
dictated by design.
 Combining the individual components to uncover errors associated with
interfacing.
7.4 System Requirement Testing and Results.

Here we compile the whole system stating from initial and proceed testing the whole system to
check out for the errors and flow control of the system.
Purpose: To ensure that the system does what the requirement specifies.
77
CHAPTER EIGHT
CONCLUSION AND RECOMMENDATION.

8.1 Conclusion.
So far we were intended in analyzing the existing system of the Dilla town all billing system
(water, electric and telecommunication services) for proposing our new system that solves the
difficulties related to the existing system. Still the existing system is running manually for water,
telecom and electric services, hence it is highly exposed to the manual related problems, like
misplacement, duplication and corruption/loss of files, high storage space requirement, unshared
nature of files, huge time consumption to manipulate and generally it degrades the effectiveness
and efficiency of the system as a whole.
By having this over the existing system our aim was to build a new system that have greater
functionality that enhance effectiveness and efficiency related parameters on the system. The
team kept in mind that the new system will bring the existing system fully functional.
To achieve our goal to design new system of the project team has spent their time on the project
on performing the tasks individually and in group based on the schedule available. The tasks to
be accomplished by the team were project selection, initiation and planning, requirement
gathering and requirement analysis and designing new system.
The team has faced many challenges even though those problems challenged, the team have
accomplished the project as much as possible.
78
8.2 Recommendation.
We would strongly to recommend that the system is open for interested groups or individuals
who wishes to add new functionalities especially to enable the system. Finally we would like to
recommend for Dilla town water, electric and telecom service to use this system by enhancing it
to the one way window it can give centralize billing system to Dilla town people.
79
9. Reference
1:ER.V.K. JAIN, System analysis and design 1st edition, 2001.
2: BRA.W, System analysis and design method, 6th edition, 3, April 2007
3:- ER.V.K. JAIN, System analysis and design 1st edition, 2001.
4:-Yi Huang and Bin Wang, “Central Billing System for Personal Bills”, IJIMT Volume 5, No 4,
August 2014.
80
10. Appendix
10.1 Appendix A: Interview Questions
1. When the Dilla town Water, Electric and Telecom service are established?
__________________________________________________________________________
____________________________________________________________
2. What are the mission, vision and the aim of the organization?
-
__________________________________________________________________________
_____________________________________
3. What are the main problem with the current manual system?
__________________________________________________________________________
__________________________________________________________________________
____________________________________
4. How can do the current billing system?
__________________________________________________________________________
__________________________________________________________________________
____________________________________
5. How can registers customer in this manually or automated?
__________________________________________________________________________
___________________________________
6. Is govern by federal or regional?
__________________________________________________________________________
7. Please tell us, about the architecture of the organization?
__________________________________________________________________________
__________________________________________________________________________
____________________________________
8. What is the main task of the service?
__________________________________________________________________________
__________________________________________________________________________
9. Who have the responsibility to prepare bill and in which time interval?
__________________________________________________________________________
___________________________________
81
10.2 Appendix B: Symbol and Description

Table 16 Symbol and Description
82
Symbol
Description
Actor.
Boundary.
Class.
Create return message.
Starting point of activity diagram.
Ending point of activity diagram.
Message line extends from the
life line of one object to the line
of another object.
Include, relation to the include use.
case to indicate inserted behavior
Use case.
83
Decision
84
85

Final Project of Centralized Bill System

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 Project of Centralized Bill System

Uploaded by

Copyright:

Available Formats

Centralized Billing System

2.3.1 Performance (Response time)..............................................................................................- 13 -

5.3 Detailed Design...........................................................................................................................- 61 -

Figure 31 Collaboration diagrams for view report....................................................................- 63 -

CBS-Centralize Billing System

CPU-Control Processing Unit.

DBMS-Database Management System.

DFD-Data Flow Diagram.

DHTML-Dynamic Hyper Text Markup Language.

ER- Entity Relationship.

GUI-Graphical User Interface.

HTML–Hypertext Markup Language.

MYSQL-My Structural Query Language.

OOA – Object Oriented Analysis.

OOD –Object Oriented Design.

OOSAD-Object Oriented System Analysis Development

OOSD –Object Oriented System Development.

PHP- Hypertext Preprocessor.

RAM-Random Access Memory.

SNNPRS - South Nation Nationality and People Regional State.

SQL- Structural Query Language.

SRS-System Requirement Specification.

UML-Unified Model Language.

XML-Extensible Markup Language.

1.2 Introduction about the project

1.3. Statement of the problem

 It is time consuming process for customer.

1.4 Objective of the project

1.4.1. General objectives

1.4.2. Specific objective

 Study the existing system and find out the problem.

1.5 Scope and Limitation

1.5.1 Scope of the project

 Generating reports of bill.

1.5.2 Limitation of the project

1.6.1 Data gathering methodology

1.6.1.2 Fact-finding Techniques

 To develop a deeper understanding of the data resources used by the system.

1.6.2. Design methodology

Regarding implementation, Hypertext Preprocessor (PHP) programming language will be

 Uses object-oriented paradigms.

1.6.3. Implementation methodology

Different hardware’s will be used to develop our project.

Computer: - computer is a machine capable of doing many things. We use it to type on it

 Highest processor speed and latest CPU.

1.6.4 Testing methodology

1.6.5. Development environment and programming tool

1.6.5.1. Object Oriented Analysis (OOA)

1.6.5.2. Object Oriented Design (OOD)

Reduced maintenance cost:

1.6.5.3 Programming tool

1.6.5.3.1 System Design and Analysis Tools

 Use case diagram.

 HTML/DHTML/XML: -Client side coding.

1.7. Feasibility study

1.7.1 Technical Feasibility

1.7.2 Operational Feasibility

 The new system fits with the existing operational system.

 Satisfy the user need or requirement.

1.7.3 Economic feasibility

 Reduce the amount of resource required in office.

 Reduce data redundancy storing in the database.

 Improve office efficiency, speed and flexibility.

1.8 Benefit of the project