Tepi Town Electric Power Billing System

Mizan-Tepi University
School of Computing and Informatics

Department of Information Technology
A Project Document Submitted to Mizan-Tepi University School of Computing
and Informatics Department of Information Technology in Partial Fulfillment of the
Requirements for the
Degree of Bachelor of Science in Information Technology
TITLE: - TEPI-TOWN ELECTRIC POWER BILLING SYSTEM
By
Name ID
1. Shambel Tesfaye…................Programmer.....................................ETR/677/04
2. Addisu Getenet…………………System designer………………ETR/050/04
3. Agumas Takele…………………Manager………………………ETR/065/04
4. Kidist Melaku……………………System analyzer……………TR/457/04
5. Leyla Mifta…………………………Refining documentation…ETR/467/04
Advisor: Mr. AdmasAbtew(Msc)
Date: 16/04/2007 E.C
MTU, TEPI
Mizan-Tepi University
School of Computing and Informatics
Department of Information Technology
A Project Document Submitted to Mizan-Tepi University School of Computing and
Informatics Department of Information Technology in Partial Fulfillment of the
Requirements for the
Degree of Bachelor of Science in Information Technology
TITLE: - TEPI-TOWN ETECTRIC POWER BILLING SYSTEM
Name and signature of Members of the Examining Board

Chairman Name__________________________ Signature________________________
Name Signature Date
___________________________ ____________ ___________
___________________________ ____________ ___________
___________________________ ____________ ___________
___________________________ ____________ ___________
___________________________ ____________ ___________
___________________________ ____________ ___________
ii
Declaration
I declare that the Project Document is our original work and has not been presented for a degree
in any other university.
Group Members:
Name_____________________________ Signature_______________ Date__________
This Project document has been submitted for examination with my approval as university
advisor.
_______________________ _________________ ________________Advisor Name

Signature Date
iii
Acknowledgment:
First of all we would like to acknowledge our Lord God, for his giving us all health to work this
project. And next we would like to acknowledge our advisors Mr-AdmasAbtew very much, he
is giving directions and leading us how to work the project from very beginning of the analysis
part to the end. Next we thank our department (Information Technology) very much; they give
us necessary facilities of computer lab and internet access. Students in our class we thank them
all for their all contributions by some time by telling direction. We would thank also for the Tepi
Town Electric power service workers no one of them opposing when we had been asking them
for the information how they work. And the customers who is using the electric power service.
Our advisors approach is not as a boss just as friends so we thanks him very much, thanks other
than we can say to him.
v
Abbreviations and acronym
VB……………Microsoft Visual Studio 2010 ENG-UPDATED-Team MYZ

MB………….Megabyte
RAM……….Random Access Memory
CD-ROM…..Compact-Disk Read Only Memory
TTEPBS……Tepi Town Electric Power Billing System
UC………….Use case
GB…………..gigabyte
HW…………..hardware
SW…………..software
E.C………….Ethiopian calendar
MTU………..Mizan-Tepi university
SQL…………structured query language
vi
Table Contents
Pages
Acknowledgment: ......................................................................................................................................... v
Abbreviations and acronym ......................................................................................................................... vi
List of figure ................................................................................................................................................ ix
List of Table .................................................................................................................................................. x
CHAPTER ONE ............................................................................................................................................... 1
1 NTRODUCTION ........................................................................................................................................ 1
1.1 Background ......................................................................................................................................... 1
1.2 Purpose ............................................................................................................................................. 1
1.3 Statement of the problem ................................................................................................................ 2
1.4 Scope of the project ............................................................................................................................ 2
1.5 Limitation ............................................................................................................................................ 3
1.6 Objective of the project .................................................................................................................... 3
1.6.1 General objective ....................................................................................................................... 3
1.6.2 Specific objective........................................................................................................................ 3
1.7 Requirement gathering methodology ................................................................................................ 4
1.7.1 Data collection methodology: ...................................................................................................... 4
1.8 Need for feasibility study ................................................................................................................. 5
1.8.1 Assessing Technical feasibility ................................................................................................... 5
1.8.2 Assessing Operational feasibility ............................................................................................ 6
1.8.3 Assessing economic feasibility:- ................................................................................................. 7
1.9 Significant of the project .................................................................................................................. 7
1.10 Assessing time schedule feasibility ................................................................................................ 7
1.10.1 Budget schedule ....................................................................................................................... 8
1.8 Operating environment .................................................................................................................. 10
1.10.2 Risk assessment:- ....................................................................................................................... 10
1.10.3 Risk Mitigation:- ..................................................................................................................... 11
CHAPTER TWO ............................................................................................................................................ 12
2 Analysis and Requirement Gathering.................................................................................................... 12
2.1 Introductions ................................................................................................................................... 12
2.2 Existing system description ............................................................................................................ 12
vii
2.3 Business rules ................................................................................................................................ 12
2.4 Function of the Existing System .................................................................................................... 13
2.5 Forms of payment for punishment ................................................................................................. 15
2.6 Drawbacks of the existing system ................................................................................................ 16
2.7 The Proposed solution .................................................................................................................. 17
2.7.1 General product functions ................................................................................................... 17
2.8 Functional Requirement ................................................................................................................ 17
2.9 Non-Functional Requirement ......................................................................................................... 19
2.10 Life cycle model used: Spiral model ............................................................................................ 21
2.11 Hardware and software considerations ..................................................................................... 22
CHAPTER THREE .......................................................................................................................................... 23
3 System Analysis Model .......................................................................................................................... 23
3 .1 Introduction.................................................................................................................................... 23
3.2 Use Case Modeling .......................................................................................................................... 23
3.2.1 Essential use cases:- ................................................................................................................. 23
3.2.2 Identified actors that will be participating in the system are: ................................................. 23
3.3 System use case model for the new system ................................................................................... 24
3.3.2 Use case Identification ............................................................................................................. 26
3.3.3 Sequence Diagram ................................................................................................................... 37
3.3.4 Activity Diagram ......................................................................................................................... 44
3.4 Conceptual class modeling .............................................................................................................. 51
CHAPTER FOUR ........................................................................................................................................... 53
4 SYSTEM DESIGN...................................................................................................................................... 53
4.1 Introduction.................................................................................................................................... 53
4.2 Purpose and Goal Design ................................................................................................................ 53
4.3 End User Characteristics ................................................................................................................. 54
4.4 Class type Architecture ................................................................................................................... 54
4.4.1 Description of class type architecture...................................................................................... 55
4.4.2 Major Module and Program Flow Diagram ............................................................................. 58
4.5 Class Description ............................................................................................................................. 60
4.6 Deployment Diagram ...................................................................................................................... 62
4.7 Component Diagram ....................................................................................................................... 64
viii
4.8 State Chart Diagram ........................................................................................................................ 65
4.9 User Interface Design ...................................................................................................................... 67
4.9.1 User interface flow diagram ...................................................................................................... 68
CHAPTER FIVE ............................................................................................................................................. 70
5. Implementation and Testing ................................................................................................................... 70
5.1 Over View of Programming Language .............................................................................................. 70
5.1.1 Areas of Application ................................................................................................................ 70
5.2 Screen shot/User Interface ............................................................................................................... 71
2 Home page for system Admin ....................................................................................................... 71
3 Home page of Bill officer .............................................................................................................. 72
5.3 Sample Implementation Algorism .................................................................................................... 76
5.4 SYSTEM TESTING ............................................................................................................................ 77
5.4.1 Unit Testing ............................................................................................................................. 78
5.4.2 Integration Test: ....................................................................................................................... 78
5.4.3 Validation Testing:.................................................................................................................... 78
CHAPTER SIX .............................................................................................................................................. 79
6 Conclusion and Recommendation ......................................................................................................... 79
6.1 Conclusion ......................................................................................................................................... 79
6.2 Recommendation.............................................................................................................................. 79
6.3 References....................................................................................................................................... 81
List of figure
Figure 1 Essential use case diagram for the new system ............................................................. 24
Figure 2 Use case diagrams .......................................................................................................... 25
Figure 3 Sequence diagram for login ............................................................................................ 37
ix
Figure 4 Sequencediagramforregistercustomer ............................................................................ 39
Figure 5 Sequence diagram for update customer information ...................................................... 40
Figure 6 Sequence diagram for generate report ............................................................................ 41
Figure 7 Sequence diagram for billing pay ................................................................................... 43
Figure 8 Activity diagram for login form .................................................................................... 44
Figure 9 Activity diagram for customer registration form............................................................ 45
Figure 10 Activity diagram for create user account form ............................................................. 46
Figure 11 Activity diagram for update user account form ............................................................ 47
Figure 12 Activity diagram for delete user account form ............................................................. 48
Figure 13 Activity diagram for search customer information ...................................................... 49
Figure 14 Activity diagram for pay for billing ............................................................................. 50
Figure 15 Class diagram ............................................................................................................... 52
Figure 16 two-tier architecture...................................................................................................... 55
Figure 17 class type architecture class type architecture .............................................................. 55
Figure 18 Major module .............................................................................................................. 58
Figure 19 Major module ............................................................................................................... 58
Figure 20 Sub Module .................................................................................................................. 58
Figure 21 Sub modules ................................................................................................................. 59
Figure 22 Hierarchical Structure ................................................................................................. 60
Figure 23 Program flow diagram ................................................................................................. 60
Figure 24 diagram of deployment ................................................................................................. 63
Figure 25 Component diagram ..................................................................................................... 64
Figure 26 State chart of View and generate report ...................................................................... 65
Figure 27 Figure 27state chart of search and delete ................................................................... 66
Figure 28 Figure 28state chart of registration and login ............................................................... 67
Figure 29 User interface flow diagram ......................................................................................... 68
Figure 30 User interface login form.............................................................................................. 71
Figure 31 User interface Admin home page ................................................................................. 71
List of Table
Table 1 project time schedule ........................................................Error! Bookmark not defined.
Table 2 budget schedule.................................................................Error! Bookmark not defined.
Table 3 hardware and software ..................................................................................................... 10
Table 4 hardware and software consideration ...............................Error! Bookmark not defined.
Table 5 Use case for secure login ................................................................................................ 27
Table 6Use case for register customer information ...................................................................... 28
Table 7 Use case for update customer information ...................................................................... 29
Table 8 Use case for generate report............................................................................................. 30
Table 9 Use case to view customer information ........................................................................... 31
Table 10 Use case for create user account .................................................................................... 32
x
Table 11 Use case for update user account ................................................................................... 33
Table 12 Use case for delete user account .................................................................................... 34
Table 13 Use case for bill payment............................................................................................... 35
Table 14 Use case for search customer information ..................................................................... 36
Table 15 layers .............................................................................................................................. 57
Abstract
The principal objective of this paper is to demonstrate and automate the capability in Tepi
electrical power services to conduct effective, automated, accurately, and inexpensively.
The need for electronically controlled service, in the absence of customer to ensure constant and
effective service distribution is a serious demand. We therefore intend to provide a solution by
constructing an electronic system that has the capability of monitoring the service of the
organization to the customers and at the same time Registration and other related service to the
customer when they need to access.
The project involves methods like data/requirement collection, system analysis and
design(object oriented approach).It also includes the use of hardware and software’s like
operating system, DBMS ,application software, PhpMyAdmin and the likes. From this project,
we hope to build automatically effective and efficient system for Tepi electric power billing
Service.
Motivation
We are initiate that Tepi Town Electric power service organization is one of the
Administrative in Tepi Town so it follows manual system that we improve to computerized
system. And our project will be developing use this system and it is reliable, good performance,
timely and the system is easy for the customer to provide service and find solution for the
existing problems.
xi
Tepi Town Electric Power Billing System
CHAPTER ONE
1 NTRODUCTION
Now a day our world is globalized with the help of technologies and other applications. For that
reason developed and some developed countries are using application and other computer
technologies to be part of the globalized world. The project “Billing system” is an application to
automate the process of ordering and billing of a “Departmental store “Power Billing System is
an Executive Information System (EIS) that determines the consumed power per unit time and
performs its computation based on the sale rate of power per unit time and other parameters. The
importance of Power Billing System (PBS) cannot be over emphasized because its calculation
reflects the exact power consumption for the prospective consumers, and in monitoring the
billing details of the electricity consumers.
1.1 Background
Tepi electric power office is an electric power organization which is in Tepi town. The
organization is part of the town administration. The organization found in Tepi Town near to the
commercial bank of Ethiopia or 100 meter far from bus station.
Tepi Town electric power service was established in 1988 E.C. At this time the number of
worker was 12 but now the number of worker is increasing from year to year and the current
worker are 35. Tepi Town electric power provides service to the customer. The customers pay
the amount of birr on timely per month and at the first time it has only 98 customers but now the
number of customer increase to 8027. The organization currently uses manual system.
1.2 Purpose
The purpose of this proposed project is to establish the method electric power billing service for
the city community. As well to establish the specification pertaining to the design and
MTU Information Technology Department 2015

1
maintenance of decentralized treatment and full service as well as facilities within the city
service boundary
1.3 Statement of the problem
Tepi electric power service is currently uses a fully manual system. As it is manual system, it
has its own problems. Customers wait for menu from the bill reader. Now the current system is
running manually. So they are facing the following problems.
 It takes more time to Waite their round.
 As everything is done manually its slow process

 No timely acknowledgement service
 Less reliability
 Security is not provided and any one can access
 Day to day current system is very costly.
 If customer wants search their details it very difficult.
 To analyze past data is more time taken.
 (Update, Search, Delete, Edit), these types of methods are not accuracy.
1.4 Scope of the project
The organization many duties:- This project will help to the customer’s in fast billing system
 Customer registration management
 Billing management
 User account management
 Generate report management
 Security login management

2
1.5 Limitation
Limitation is the thing that our system unable to perform because of
 when reader wants to read he/she going to each customers house

 The customers pay by going to the organization where the application is available(it is
not online)
 It is limited for Tepi Town electric power service only
 If power breaker damage and is there another need of maintain problems in the home
she/he call by telephone or directly going to the TTEPS
1.6 Objective of the project

1.6.1 General objective
 To develop a new system and to change the manual system into computerized system.
 Each activity to be done by the computer without any complexity, error, confusion and to
give accurate and complete service to the user.
 To develop a customer registration system that gives a reliable and timely response to
user.
1.6.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 and solve problems
Like:-
 Customer can get service in short time.
 Minimizes the work load of organization employers.
 Minimizes the cost of resources.
 Makes the working process attractive and easy to use.
3
 Utilizes human and material resource efficiently.

 Demonstrate the potential of the system for further application and scalability.
 The Admin can access customer’s information easily.
 Keeping customer data consistently and security.
1.7 Requirement gathering methodology
In order to design this project proposal we have examined different methodologies that will help
us to investigate ways of gathering information.
1.7.1 Data collection methodology:
The collection of information is the main core of the system analysis the information we used to
describe the end to end process of the existing.
 Interviewing
 Direct observation
 Reading stored document related to system.
 Questioner
1.7.1.1 Interview
The interview was face-to face discussion with the members of organization who are great
contributing of the organization in particular for running the organization program.
1.7.1.2 Direct Observation

We have examined physical observations on how employees perform their jobs to analyze the
existing system.
1.7.1.3 Reading documents

To have detailed awareness about our project we used documents such as books. During the
analysis of documents, we give a special consideration to those documents which can bring more
features to our system.
1.7.1.4 Questioners
We would conduct questioners for the Tepi town electric power service to study the existing
system and develop the new system.
4
1.8 Need for feasibility study
The feasibility study is carried out to test whether the proposed system is worth being
implemented. Feasibility study is a test of system proposed regarding its work ability, its impact
on the organization ability to meet user needs and effective use of resources. It is usually carried
out by a small number of people who are familiar with the information system techniques,
understand the part of the business or organization that will be involved or effected by the project
and are skilled in the system analysis and design process.
The key consideration involve in the feasibility study are:
1. Technical feasibility
2. Operational feasibility
3. Economic feasibility
1.8.1 Assessing Technical feasibility
Technical feasibility centers on the existing computer system (hardware, software etc.) and to
what extent it can support the proposed system addition. The organization has the ability to
construct the proposed system. The group members have a clear understanding of the hardware,
software and operating environment to be used ,the member tried to make the project size small
and less complex to minimize risk and use standard technologies. If the budget is serious
constrain then the project is judged not feasible.
Project size:
 Even though the size of the project large for the team members the team members work
in maximum effort accomplish the whole project task
The technologies and the environment which are used in this project are:
This project has less risk becase it using standard technology such as:-
Software
Frontend

5
 Language used: VB. We use this language is supports event driven programming feature.
Back end
 Supporting Software: SQL Server 2010. This is used to storing data in the form of tables.
It is easy to use.
Operating system:
 Platform: Windows 7. Our system requires window operating system, which is easily
available.
Hardware:
 Intel based processor-run computer system, which have keyboard and mouse as input
devices. This has been decided for its case of availability and up-gradation.
User group:-
 The project interface gives easier interaction to the user, it is very understandable and it
does not require more computer knowledge to use.
1.8.2 Assessing Operational feasibility
From the discussion that the team proceeds with the system users and peoples in the management
area, the proposed system will solve the existing problems to a great extent. This proposed
system is operationally feasible because every mentioned problem was raised from the users
themselves and every solution to address the problems are proposed by making discussion with
the users.
Moreover, as the system development will be done according to appropriate principles and
method, the new system most likely solves the problem identified.

6
1.8.3 Assessing economic feasibility:-
The procedure is to determine the benefits and savings that are expected from a candidate system
and compare it with the costs. If a benefit outweighs costs, then the decision is made to design
and implement the system. Otherwise further alterations are made in the proposed system
 Manpower cost
 Hardware and software cost
1.9 Significant of the project
Tepi town electric power billing and sewage enterprise is not using the computerized working
system hence it is the serious problem in time management and to perform their work efficiently.
So making the system computerized and web based information system will help them to work
efficiently furthermore this project in significant in that enable the system.
 It help to decrease work overload
 To save time and cost
 To increase profitability
 To increase customer satisfaction
 Easy to use, effective and efficient

 Accurate results and More reliable
 Easy maintenance and to increase employee attraction
 Fast access and more secure.

 More feasibility and Provides high consistency
1.10 Assessing time schedule feasibility

7
It is determining start and finish date for project activity.
1.10.1 Budget schedule
This much amount of money were estimated (required) for finishing the project

8
Development Technologies and Tools
 Application Technology: visual basic.net (Microsoft visual studio 2005 framework 2.0)
 Front end: VB.6
 Back end database design: SQL server
 Languages Used: visual basicVB
 Interface design: Adobe Photoshop CS3,CS4

9
1.8 Operating environment
Table 1 hardware and software
1.10.2 Risk assessment:-

 The team tries to figure out and control the risk that may happen in the electric power
service system through group discussion the risk that will be controlled under the team
are:-
Project size:-
 The project team tries to control the project size through length of development schedule.
Electric power break:-
 According to the current electric power shortage of country we have faced a great
problem to finish our project according to the time schedule.
Project structure:-
 Degree to which development effort is new and/or innovative
 The logical structure
 The structural change

10
Analysis
 Familiarity with proposed technology
Virus:-
 The file or document will be lost by virus
End user:-
 The number of end users that use the system
 Familiarity with proposed system Application environment
1.10.3 Risk Mitigation:-

 Avoid unnecessary information
 Antivirus
 Continue back up
 Documentation and analysis flow

11
CHAPTER TWO
2 Analysis and Requirement Gathering
2.1 Introductions
Now a day there is a lot about the systems being automated. The current system which is
manually working system his big problems in their day-to-day operations. This is because, what
was prepared by human which is exhaustive, time consuming and boring for employees. So by
using computer technology, one can bring the simple and more secured way of data handling,
manipulating, retrieving and searching systems that can be considered as the way out to some of
the problems in the manual system. To do this system, desktop application is preferred from
other programming languages because the customers are not familiar with computerized system
(e.g. internet services) and also decreases ambiguity of employees when customers pay their
amount of birr.
2.2 Existing system description
Tepi town electric power billing system is now full manual. It is not handles customer
information in a computerized system, it makes problem to find full information about their
customer. Among that full manual activity customer registration is the most common system
activity. New customer registers to the system first on paper by giving full information to get
electric power service from system. The existing system have no fast retrieval of data time,
consume large volume of paper work and more man power, waste of too many hardware
materials and lose of their files. All the necessary records of the above management activities are
kept manually on papers and stored in file cabinet.
2.3 Business rules
Our system Business rules are used to perform system functionality correctly and effectively.
The followings are some of the system business rules.
Rule 1: Authorize to the system

 Authorized user must have a valid user name and password.

12
Rule2: Correct information

 The authorized user checks the filled customer’s information and the entered information are
correct.
Rule 3: Validate customer’s information
 The authorized user registers the customer’s information and the system validates.
Rule 4: Customer make member of system when fulfill registration criteria.
 Customers to register in the system they must have house map and Keble identity card
and report paper. If customers not have their own house, it must be written approval later
from Tepi town administration. These criteria are used to identify customers who live in
Tepi town.
Rule 5: The reading number in kilowatt to calculate monthly payment.
 To pay customer based on their kilowatt reading number. All customers are must pay
monthly based on their reading. They must know the date that the customer performs
payment to avoid punishment.
Rule 6: officer may be performing penalty.
 Every member of customer must be pay with in predefine date. If customer not pay, Bill
officer punish customer by birr. Customers not only pay money for punishment it may
also cancel from the customer list when they cannot pay their amount until three month
consequently. After that electric power services are stop.
2.4 Function of the Existing System
The basic existing system functions of the organization are:

Customer registration
 It is done by customer service by collecting the necessary data from the user.
 Customers to register in the system they must have house map and Keble identity card
and report paper.
Bill calculation
 Customer’s data store and bill calculating was using computer software which have
SQL2008 server.

13
 Backup data was stored in manually by using cabinet and suspension card and also use
Ethiopian electric power corporation head office web site as a backup.
 Customer must inform the office if his/her reading value was not done in timely manner
by being physically available at the office.
 Every member of customer must be pay with in predefine date. If customer not pay, Bill
officer punish customer by birr.
 If customers not pay until three months consequently, they cancel from customer list and
do not get electric power service.
Report generation
 The organization makes a general report about the billing system once at the end of the
month and generates the report.
Maintenance reporting
 Customers inform physically or by telephone to customers services and selling office
when they get a problem. Standby technicians are go to the customer and maintain a
problem
 Employees get feedback about their services from their customers using suggestion box.

14
2.5 Forms of payment for punishment
ETHIOPIAN : ELECTRIC POWER CORPORATION No _____________

Date _____________
ADDIS ABABA
DISCONNECTION ORDER FOR SUPPLY OF ELECTRICITY
_______________________________________________________________________________
Customer's name________________________________________________________
Address_____________________________________________________
Contract No. _________________________ A/CNo. _____________________ Meter Book No. ______________
Please Disconnect Supply of Electricity
REASON FOR DISCONNECTION
For Non Payment Others At customer's Request
Remark_________________________________________________________________________
Prepared by_______________________________ Consumer's Signature _________________________
Date _______________________ Consumer's Division ___________________________________
Remark ___________________________________________________________________________
Inspection Division __________________________________ D ate ________________________________

15
2.6 Drawbacks of the existing system
The organization has many drawbacks. Some of these are list below.
Customer information not properly handling: -
 They use paper to store customer information's.
Lack of security of data: -

 All files are kept on cabinets by a box file they are exposed to theft and other
environmental disaster.
Time consuming: -
 As it was manual using paper, it is difficult to generate daily, monthly and annually
report on timely and it may have errors as they work in quickly.
Tiredness of employees: -
 As they work manually searching some data is takes too much time for the employees
who assigned on this work and they are unsatisfactory on the existing system which leads
to endanger on the sustainability of the company.
More man power is needed: -
 Requires many numbers of peoples to billing selling and maintenance.
Lack of materials: -
 They have no enough materials that used to facilitate their services like computers,
printers.
 Duplication of data occurs when data input in to the system.
 Checking the validity of input data is difficult
 The data stored takes more rooms or place
 After customers submit registration form the employee check the validity of customer’s
information line by line the customer’s response time is low.
 The services provided by the office are not as fast as possible because the service providers are
busy with the paper and paper related activities.

16
2.7 The Proposed solution

2.7.1 General product functions
 The key solution to avoiding all the problems mentioned previously is to find a unified
way that is desktop application system.
 The proposed system of our project changes the existing full manual process of the
organization to new system.
 To eliminate drawback of the existing system, there is some additional system
requirement add to new system.
 The new system gives full system functionality that is needed by system user to perform
system functionality.
 Among that system functionality customer registration, billing calculation and check if
the customer pay or not pay as well as print bill paper.
 Customers get service in short time.

 The system minimizes the work load of organizational employers.
 The system minimizes the cost of resources.
 The system makes the working process attractive and easy to use.
 The system supports to utilize human and material resource efficiently.
 Demonstrate the potential of the system for further application and scalability.
 The authorized employee can access and modify customer’s information easily.
 The system keeps customers data consistently.
2.8 Functional Requirement
In software engineering, a functional requirement defines a function of a software system

or its component. A function is described as a set of inputs, the behavior, and outputs.
Functional requirements may be calculations, technical details, data manipulation and
processing and other specific functionality that show how a use case is to be fulfilled.
They are supported by non-functional requirements, which impose constraints on the
design or implementation (such as performance requirements, security, or reliability).As
defined in requirements engineering, functional requirements specify particular behaviors
17
of a system. This should be contrasted with non-functional requirements which specify

overall characteristics such as cost and reliability.
Functional requirements these are statements of services the system should provide, how
the system should react to particular inputs, and how the system should behave in
particular situations. It specifies the software functionality that the developers must build
into the product to enable users to accomplish their tasks.
Customer data process:-
 Customer registration
 Billing payment
 Update Customer’s information
 Search and Delete Customer’s data
 Admin view customer’s information
 Print bill paper
 New customer needs to first register before any activity, so this Functional requirement is
used to register the new customer in the system. The system checks all of the required
information was entered. If yes the system updates the customers recorded in the store
customer table in the data base. The system display confirm message.
 The system is desktop application that provides successfully registration of customers
which are under the business rule of the office.
 The system should provide to modify record that is deleting, editing and inserting as well
as retrieving the required information.
 The system should display message when employees of the Tepi town electric power
service do their task successfully or not.
 The system should display full information for the employee from the database.
 The system should have well organized information storage and accessing mechanism.
 The system should allow generating report for the organization.
 The system print the bill paper when the payment is successful

18
2.9 Non-Functional Requirement

In systems engineering and requirements engineering, non-functional requirements are
requirements which specify criteria that can be used to judge the operation of a system, rather
than specific behaviors. This should be contrasted with functional requirements that specify
specific behavior or functions. Non-functional requirements are often called qualities of a
system. Other terms for non-functional requirements are "constraints", "quality attributes",
"quality goals" and "quality of service requirements
 Availability: the developed system is almost available at any time when an employee
wants its service.
 The system shall have high availability
 The system shall not have unexpected downtime
 Data integrity
 Data will be critical to its success as a system
 Maintainability:
 The system shall be easily maintainable.
 Adaptability:
 The system should compatible with different standards in order to be usable via
operating systems a wide variety of environments.
 Accessibility:
 The officers can access the system easily by their user name and password.
 Documentation
In the process of interacting with this system the users and the users of ORS can be easily access
the software using the following documentation types:
 Help desk
 User guides
 Documentation (system design and architecture).
 Security:
 The next is about the security in our system. In our design we gave more that
concern to the security of the system in the case of very sensitive data. That
means, we have given attention to data security, because there are sensitive
data which need protection, so must be authentication requesting such as user
19
name and password. The system must be protected from being accessed by
unauthorized costumer.
 In order to make the system safe from an unauthorized access and
modification, the system uses a login account to differentiate among the
different users of the system on the inventory management system to protect
the sensitive customer and material information. This enables the system to
verify who has logged in using the correct logging account provided and
display the right form associated with that user.
 Compatibility:
 As we have already explained above, the system was expected to be independent
of any hardware or software version of any computer system, which indicates the
system were supported by any operating system, i.e. compatible with any
necessary software's.
 Usability:
Usability is a term used to denote the easy with which people can employ a particular tool
or other human-made object in order to achieve a particular goal. Usability can also refer
to the methods of measuring usability and the study of the principles.
 More efficient to use—it takes less time to accomplish a particular task
 Easier to learn—operation can be learned by observing the object
 More satisfying to use
 Performance
 Throughput
 The current working system has a low level of throughput as viewed under globalization
era.
 Reliability
 The system must be efficient and reliable .the system must be designed and developed
considering the memory and the processor requirement for each sub-system.

20
2.10 Life cycle model used: Spiral model

In the proposed system the spiral model is used. The spiral model will give the benefit of adding
the new features and if at all required it provides the necessity of doing changes in the design
part to some extent, as there are quite number of enhancements are proposed on the system at
later stage, hence the spiral model approach is being adopted for the system design and
implementation.
Fig 2.8: Spiral Model
Requirement analysis phase results in the specification of software’s operational characteristics;

It allows software engineer to elaborate on basic requirements and build models that depict user
scenarios. Software design is an iterative process through which requirements are translated into
a “blue print” for constructing the software. It provides a complete picture of the software,
addressing the data, functional and behavioral domains from an implementation perspective. The
coding phase is the translation of the detailed design to the executable code using a programming
language. In the coding phase, every module is identified and specified in the design document is
independently coded and unit tested.

21
2.11 Hardware and software considerations
Here the requirements can be viewed in two directions the user side and the organizational side
(servers).
Table 4 hardware and software consideration

22
CHAPTER THREE
3 System Analysis Model

3 .1 Introduction
System analysis is the part of the systems development life cycle in which you determine how
the current information system functions. During requirement determination the system analyst
gather information on what the system should do from as many sources as possible: from the
user of the current system, from observing the users and from report forms, interview, and etc.
for developing proposed system we have used interview, practical observation, and document
analysis to determine the requirement of the system.
3.2 Use Case Modeling

3.2.1 Essential use cases:-
Is a primary importance early in a project’s analysis phase. Their purpose is to document the
business process that the application must support without bias to technology and
implementation. The narrative in the Essential use case is to be expressed in the language of the
application domain and of users. It identifies use case and an actor of the existing system. A use
case is a set of scenarios tied together by a common user goal. A scenario is a sequence of steps
describing an interaction between an authorized user and a system.
3.2.2 Identified actors that will be participating in the system are:

 Admin
 Clerk
 Bill officer
Task for clerk:
 Register customer information

 Search customer and view

23
Bill officer: - an employee, who works on customer service office, which have the following
responsibilities.
 Update customer, search and view
 Makes a decision when a customer deleted
 Manage bill, update bill, delete bill
 Generate report
Task for Admin:
 Generate reports
 View the data from the database and search
 Create account
 Update account
 Delete account
3.3 System use case model for the new system

During analysis, the main goal is to involve essential use cases into System use cases. In system use case,
we include high-level Implementation decisions. For example, a system use case refers to specific user
interface-components such as screens, or reports. System use case model is composed of a use case
diagram and the accompanying documentation describing the use cases, actors, and associations. A use
case describes a sequence of actions that provide a measurable value to an actor and is drawn as stick
figures.
3.3.1 Figure 1Essential use case diagram for the new system

24
Figure 2Use case diagrams
3.3.1.1 Documenting use cases

Documenting use case is use to clarify the idea of use case and makes the process that under goes in each
use case easily understandable. Below are the lists of the use cases that are identified for TTEPS.

25
3.3.2 Use case Identification

The following are the use cases identified for developing use case diagram of the system: -
There are use cases:-
 Use case 01 : Login

 Use case 02 : Apply customer registration
 Use case 03 : Update customer information
 Use case 04 : Generate report
 Use case 05 : View customer information
 Use case 06 : Create user account
 Use case 07 : Update user account
 Use case 08 : Delete user account
 Use case 9 : Manage billing
 Use case 10 : Searching customer information
Use case and their descriptions
Login

26
Use case number UC 01
Use case name login
Actor Admin/Bill officer /Clerk
Description Allow Admin/Bill officer /Clerk to login into the system(TTEPS)
Include
Precondition Admin/Bill officer /Clerk have valid user name and password.
Basic course of action User action System response
1. Admin/Bill officer /Clerk want to 2. The system will display

login into System. user interface window
request to enter.
3. Admin/Bill officer /Clerk enter
password and user name & submit the 4. system checks validation
form. of username and password
5. Admin/Bill officer /Clerklogin into

the system.
6. Use case end.
Alternative course of action If the inputted user name and password are not valid the system will
loopback to step 3 and request to insert again
Post condition The Admin/Bill officer /Clerk login in to system(TTEPS)
Table 2 Use case for secure login
Register customer
27
Use case name Register customer
Actor Clerk/Admin
Description The system allows Clerk/Admin to register customer information
Include UC01
Precondition Clerk/Admin should have valid user name and password to enter to the
system.
1. Clerk/Admin wants to register 2. The system displays the

customer information. record form
via“UI05customer
3.Clerk/Admin enter the required
information record”.
information via “UI05customer
information record” 5 the system validates and
displays that customer
4. Clerk/Admin submits the recorded
record are successfully
information.
stored.
6. Use case end.
Alternative course of action If inputted invalid data entry the system will loopback to step 3 and
insert again
Post condition Register Customer information
Table 3Use case for register customer information
Update customer information

28
Use case name Update customer information
Actor Bill officer
Description The system allows Bill officer to update customer registration
Include UC01
Precondition Before starting to update customer information Bill officer should be

login into the system and there should be a data to be updated.
1. The Bill officer logs to his account 3. The System displays

from the home page of the TTEPS search by customer ID)
2. The Bill officer Search customer by 5. The system displays the

clicks on the search button. searched result
4. The Bill officerinsert customer id and 7. validate the data entered

click button and update the database
6. The Bill officer clicks on the update

button and modify the register
8. Use case end.
insert again
Post condition Update customer information
Table 4 Use case for update customer information
Generate report

29
Use case name Generate report.
Actor Admin/Bill officer
Description The system allows Admin/Bill officerto generate report
Include UC01
Precondition Admin/Bill officer should get data from TTEPS
1. The Admin/Bill officer log to his/her 2.The system display user

account from the home page of the interface
TTEPS
4. The system Validate for
3. Admin/Bill officer insert customer id the availability of the
and click button information in database
6. Generate the information and prints 5. The system will display

the data. data to be generated.
7. Use case end.
Alternative course of action If data not available the system will loopback to step 3 and search
again
Post condition The systems generate report.
Table 5 Use case for generate report
View customer information

30
Use case name View customer information
Actor Admin/Clerk/Bill officer
Description The system allow Admin/Clerk/Bill officer to view customer

information
Include UC01
Precondition The Admin/Clerk/Bill officer Should login into system by using valid
username and password and there must be a data to be viewed
1.The Admin/Clerk/Bill officerclick on 2. the system display

view and search information to be privileges’
viewed
3.The System displays view
4.Admin/Clerk/Bill officer view the data
result
5.usecase ends
Alternative course of action If data entered is not available
1 The system will loopback to step 1 and search again
Post condition View customer information
Table 6 Use case to view customer information
Create user account

31
Use case name Create user account
Actor Admin
Description The system allow the system Admin to create account
Include UC01
Precondition System Admin should have valid user name and password to access the
system and perform the task
1. The Adminlogin and opens create 4. The system checks the

user account form. validity of the user
credential.
2. The Admin enters user name and
password and password
3. The Admin clicks on Create button. 5. System display account

created
6.The Admin is giving the account to an
employee.
7. Use case end

Alternative course of action If the user account already exists
1: The system flags an error message
2: The Admin tries another combination
Post condition Creates user account
Table 7 Use case for create user account
Update user account

32
Use case name Update user account
Actor Admin
Description The system allow the system Admin to update user account
Include UC01
system and there must be user account to be update
1. The system Admin login and 4. The system checks the

opens update user account form. validity of the entered user
credential.
2. The system Admin enters user
name, current password and new 5. System display Password
password. updated.
3. The Admin clicks on Update

button.
6 Use case end
Alternative course of action If the user name and password doesn’t match.
1: The system flags an error message.
2: The system Admin tries again.
Post condition Password will be changed
Table 8 Use case for update user account
Delete user account

33
Use case name Delete user account
Actor Admin
Description The system allow the system Admin to block access to the system
Include UC01
system and there must be account to be deleted
1. The Adminlogin and opens delete user 4. The system

account form. checks the existence
2. The Admin enters user name and password. of the entered user
3. The Admin clicks on Delete button. credential.
6. Use case end 5. User account

deleted.
Alternative course of If the user name and password doesn’t match.

action
1: The system flags an error message.
2: The system Admin tries again.
Post condition Deleted user account
Table 9 Use case for delete user account
Pay Billing

34
Use case name Billing payment
Actor Bill officer
Description The system allows Bill officer to manage Billing
Include UC01
Precondition Before starting to manage Billing Bill officer should be login into the
system and there should be a data to be consumed read in KWPH.
1. The Bill officer logs to his account 3. The System display bill
from the home page of the TTEPS form
2. The Bill officer go to payment button 5. validate the data entered

and click it and payment the database
4. The Bill officer insert custScno and 6. display bill form

clicks on the submit into the system
8.Automatic calculate and
7. The Bill officerinsert current reading display result
value and click calculate button
10.displaye successful
9. The Bill officer click print button
11. Use case end.
insert again
Post condition Customer will pay for bill
Table 10 Use case for bill payment

35
Search customer information
Use case name Search customer information
Actor Admin, Bill officer, Clerk
Description The system allows all actors to search every individual
customer information
Precondition Customers must register and there must be data to be searched
1. The actor logs to his/her account from 2. The system display user
the home page of the TTEPS interface
3.user insert id 5. The system check id

which are inserted by user
4. click submit button
and id that occur in
7.use case end database.
6. The system display.

customer information
Alternative course of action If the id invalid the system will loopback to step 3 and insert again
Post condition View individual customer information
Table 11 Use case for search customer information

36
3.3.3 Sequence Diagram
Sequence e diagram is used to show the sequence of actions, interaction of an object with the Actor’s and
time frames of the system.
A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the
instances participating in the interaction by their “lifelines” and the stimuli that they arranged in
time sequence. It does not show the associations among the objects.
Shows the participating objects by the lifelines and the instructions among this objects arranged
in time sequence by the message they exchange with one another.
Figure 3 Sequence diagram for login

37
Main Home Login Login Login

Admin form Database
page controller <<UI>>
Open()
Click login
Enter username
and password
Send
Create ()
Login
check
Invalid ()
Response successful
Figure 3 Sequence diagram for login

38
Figure 4 Sequencediagramforregistercustomer
Main Home Login form Registration

Clerk Login controller Database
page form
wants to customer
register
Click login
Enter username
and password
Send
Create ()
Fill customer info
Apply
check
Try again Invalid ()
successful
register
Figure 2 Sequence diagram for customer reg

39
Figure 5 Sequence diagram for update customer information
Main Home Login form Cust update Cuat update

Bill officer Database
page controller <<UI>>
wants to customer
info update
Click login
Enter username
and password
Send
Create () valid
Invalid
insert customer ID
Enter data to be
update
update
check
Try again Invalid ()
successful
update
Figure 5 Sequence diagram for update customer information

40
Figure 6Sequence diagram for generate report
Main Home Login form Cust generate Generate

Bill officer Database
page controller report
wants to customer
info update
Click login
Enter username
and password
Send
Create () valid
Invalid
Check report
Select report
generate
check
Try again empty
successful
generate
Figure 6 Sequence diagram for generate report

41
5 Sequence diagram for view customer information
Login form view viewAppli

Admin Home page Database
controller <<UI>>
wants to customer
info view
Click login
Enter username
and password
Send Create ()
check
Go to view
button
empty
Try again
Click view link
view
successful
viewed
Figure 5 Sequence diagram for view customer information

42
Figure 7 Sequence diagram for billing pay
Login form Bill controller Bill Database

Bill officer Home page interface
Bill officer wants to

open{}
Click login
Enter username
and password
Send Create ()
Click bill
check
Insert cust bill
SCno
Insert current Try again invalid

reading value
Click calculate
Display bill
print form &amont
successful
Figure 7 Sequence diagram for billing pay

43
3.3.4 Activity Diagram
Activity diagrams model is a high level business or processes or transitions between states of a
class. In this activity diagram tried to document the flow of logic for the major business
processes. Illustrate the dynamic nature of a system by modeling the flow of control from
activity to activity and something diagrams are red from top to bottom and have branches and
fork to describe conditions and parallel activities.
Rounded rectangles represent actions, diamonds represent decisions.
Figure 8 Activity diagram for login form
Figure 8 Activity diagram for login form

44
Figure 9Activity diagram for customer registration form
Figure 9 Activity diagram for customer registration form

45
Figure 10Activity diagram for create user account form
Figure 10 Activity diagram for create user account form

46
Figure 11 Activity diagram for update user account form
Figure 11 Activity diagram for update user account form

47
Figure 12 Activity diagram for delete user account form
Figure 12 Activity diagram for delete user account form

48
Figure 13Activity diagram for search customer information
Figure 13.Activity diagram of search

49
Figure 14Activity diagram for pay for billing

50
Activity 14 diagram for pay for billing
3.4 Conceptual class modeling
Conceptual modeling is the activity of finding out which concepts are important to our system.
This process helps us to understand the problem further, and develop a better awareness of our
customer’s expectation. The UML does not tell us how or when to do conceptual modeling, but it
does provide us with the syntax to express the model. The model we used is class diagram for
conceptual modeling.
Class diagrams show the static structure of the model, in particular, the things that exist (such as
classes and types), their internal structure, and their relationships to other things.

51
Figure 15 Class diagram
communicate
1 User account
has -Username : char has
1 -Password : String
1 1
1
1 1
Bill officer 1 has
-username : char
-password : String Administartor Clerk
Customer
-officer id : int -fname : String -fname : String
-sex : char -Cust id : int -lname : String -lname : Single
-position : char -Fname : String -sex : char -sex : String
-tell no : int 1 -lname : String -position : char -clerk id : string
+update cust info() -Age : int -admin id : int -position : string
1 +view cus info() -Sex : char
manipulate -tell no : int -tell no : String
+generate report() -Job : char
+Billb payed() 1 +Generate report() +Register()
0..1 -Address : String * +View() +Search()
-Nationality : char
1
+Search() +Accept comment()
1 -Region : String
1 +Create account()
+Register() +Update account()
1..* 1
+Update() +Delete account() 1
+generate() recorded
registered
1
received
1..*
Has prepare 1
1 Registration
1..* Bill
-Sc no : string -Register no : int
Generate report -name : string -Register date : char
Counter reader
-Biin no : string -Register time : float
-report type : string -Fname : String
chech -Current read : int +Apply()
-repport date : string -Lname : String
-Previou read : int
-report no : int -sex : char
1..* -Consumption : int
+view() -Consumption Kwph/kva : int -Reader id : int
-payment mode : String -Tel no : int
1 -reading date : Date +Read in Kwph() view
-meter no : int
1..* -Block rate : float
1..* 1..*
-Bill preparation date : String
-consumption period : int
-contract deposits : int
View
-Due date : string
-info type : string
-Bill item : char
-view date : string
-contract no : int
+view()
-meter reading sequence : string
+Calculate bill()
+show()
+print()
report 1..*
view
Class diagram

52
CHAPTER FOUR
4 SYSTEM DESIGN
4.1 Introduction
The purpose of system design is to provide an over view as to how to actually build the proposed
system and to obtain the information needed to derive the actual implementation of the system
System design is the process and focuses on decomposing the system into manageable parts.
During requirements analysis, we concentrated on the purpose and the functionality of the
system. During system design, we focus on the processes, data structures, and software and
hardware components necessary to implement it.
4.2 Purpose and Goal Design

The design goals represent the desired qualities of the system and provide a consistent set of
criteria that must be considered when making design decisions. Based on the nonfunctional
requirements and the information elicited from the users, the following design goals are
identified.
Interoperability: The proposed system have good user friendly interface that provides to the
system user of the station to easily interact with the system.
Availability: The system should available for any valid users of the station as long as the service
provider is available unless it is shut down by the Admin.
Expandability: If someone wants to modify and dynamically developing the new system based
on the standard of our system, the detail design of the developed system leads to the desire
situation that will be added for the future.
Usability: The system should have a simple and easy graphical interface that users can
understand quickly.
53
Portability: The system should be well suited to work on any machine running windows
operating system.
Compatibility: Our system has compatible with windows because we get easily and users are
customizing with the software.
Security: The purpose of developing computerized system for Tepi town electric power service
file management system is to handle personal information of customer with a great care through
the station. In order to achieve this security measure the following alternatives are taken as a
solution.
 Authentication: No one can access the data rather than the authorized person of the
station because the new system has granted privilege for authorization and authentication
with user accounts and password.
 Database security: Security feature of Access server to ban the database from an
unauthorized access will be implemented.
4.3 End User Characteristics

User of the system should be:-
 Should have basic knowledge about computer.
 She/he should not be blind.
 She/he must also have basic knowledge of English.
4.4 Class type Architecture
System architecture or class architecture is the conceptual model that defines the structure, behavior, and
more view of the system.
System architecture can comprise system components, the externally visible properties of those
components, the relationships between them. It can provide a plan from which products can be procured,
and the systems developed, that will work together to implement the overall system.
The system in two-tier architecture as shown below.

54
Figure 16two-tier architecture
4.4.1 Description of class type architecture

The Class Type Architecture of the Tepi town electric power billing System has the following
layers will be discussed in the table below one by one.
 Interface (user interface and system interface) Layer

 Process (application and controller) Layer
 Business (Domain) Layer
 Data (Persistence) Layer
 System Layer
Figure 17class type architecture class type architecture

55
Interface
(User Interface System Interface)
System
Domain Process
(Infra structure
(Busness) (Aplication Software)
platform)
Persistence
(Data)
Data source
Class type architecture

56
Layers and their description
Table 12 layers

57
4.4.2 Major Module and Program Flow Diagram
3.3.1 Figure 18 Major module for user interface
Figure 19 Major module
3.4.1.1 Major module for Bill officer
Figure 20 Sub Module

58
Module for Admin
clerk
Record Generate Report Search
Figure 21 Sub modules for clerk

59
3.4.2 Figure 22 Hierarchical Structure
Figure 23 Program flow diagram
4.5 Class Description
A class diagram is a component of unified modeling language that shows level of association
among classes and objects. It also shows multiplicity associations, that means how many objects
participate on the association. Class diagram shows the role of objects or classes and
aggregations. We model classes to represent the static structure of how the system will be built.
Class model in design is that focus on the solution domain.

60
We describe each classes of the class diagram created previously.
Bill officer
Attributes
 Full name string type which holds the first name, middle name and last name of the officer.
 ID, is string type that holds the identity (number & character) of the officer.
 Password is string data type that holds to identity legal owner of the system.
Operation
 Pay , Update, Search, Generate report
Manager
Attributes
 Full Name, string type which holds the first name, middle name and last name of the
Manager.
 ID, is string type that holds the identity (number & character) of the Manager.
Operation
 Viewinfo, Generate report, manage user and Search.
Clerk
Attribute
 Full name, string type which holds the first name, middle name and last name of the clerk.
 ID, is string type that holds the identity (number & character) of the clerk.
 Operation
 Register, Search view.
Account

61
Attribute
 Username is string data type that holds the name given.
Operation
 Verify name, Verify password.
Customer
Attribute
 Full name is a string type which holds full name of the customer.
 Customer ID is string type which holds the identification of customer.
 Age, is string which holds age of customer.
 Sex, is a character type that holds the gender (in terms of M and F).
 Job is string which holds the job of the customer.
 Address, is a string which holds address of the customer.
 Nationality is a string which holds the nationality of the customer.
 Religion is a string which holds the religion of the customer.
4.6 Deployment Diagram
Deployment diagrams are implementation type diagrams that describes the physical structure of
the hardware and software of the system. They depict the software components, processors and
the device that make up the systems architecture. Deployment diagrams is concerned with the
physical operation of the application. This includes issues as the network layout and location of
the components on the network.

62
Deployment diagrams show:

 The configuration of run-time processing elements and the software
components, processes, and objects that live on them. Software component
instances represent run-time manifestations of code units.
 The physical communication links between hardware items (machines and
other sources, such as printers).
 The relationship between physical machine and processes-what runs where?
Figure 24 diagram of deployment

63
4.7 Component Diagram
Component diagram show the interaction and dependencies between software components. It
helps to model the physical aspects of an object oriented software system. Those software
components including run-time components, execute components and source code of
Components.
Registration
Search cust
info
administrator
Update
Cust info
Delete
Cust info
security
Tepi Town View
Electric Billing Cust info
Bill officer
system
persistent
Generate
report
Create
account
Accountant
Update
account
Delete
account
payment
Figure 25 Component diagram

64
4.8 State Chart Diagram
State chart modeling is used to show the sequence of states that an object goes through, the
events that cause the transition from one state to the other and the actions that result from a state
change. The following figure shows the state of the objects of the corresponding use cases.
Figure 26 State chart of View and generate report

65
Figure 27Figure 27state chart of search and delete

66
Figure 28 state chart of registration and login
4.9 User Interface Design
User interfaces describes how the user interacts with the new system interfaces. User interface
guides the user with user friendly commands how to operate the system. Most of the time user
interfaces does not need training of users. The following user interface describes Tepi town
electric power service database management system operating environment.

67
4.9.1 User interface flow diagram
Figure 29 User interface flow diagram

68
TABLES
Customer
Users

69
CHAPTER FIVE
5. Implementation and Testing

5.1 Over View of Programming Language
VISUAL BASIC is a high level programming language which evolved from the earlier DOS
version called BASIC. BASIC means Beginners' All-purposeSymbolic Instruction Code. It is a
relatively easy programming language to learn. The code looks a lot like English Language.
Different software companies produced different versions of BASIC, such as Microsoft
QBASIC, QUICKBASIC, GWBASIC, and IBM BASICA and so on. However, people prefer to
use Microsoft Visual Basic today, as it is a well-developed programming language and
supporting resources are available everywhere.
5.1.1 Areas of Application
Using Visual Basic's tools, you quickly translate an abstract idea into a program design you can
actually see on the screen. VB encourages you to experiment, revise, correct, and network your
design until the new project meets your requirements. However, most of all, it inspires your
imagination and creativity.
Visual Basic is ideal for developing applications that run in the window operating system. VB
presents a 3-step approach for creating programs:
1. Design the appearance of your application.

2. Assign property settings to the objects of your program.
3. Write the code to direct specific tasks at runtime.
Visual Basic can and is used in a number of different areas, for example:
 Education
 Research
 Medicine
 Business
 Commerce
 Marketing and Sales
 Accounting

70
5.2 Screen shot/User Interface
1. Login Form
Figure 30User interface login form
2 Home page for system Admin
Figure 31 User interface Admin home page

71
3 Home page of Bill officer
2 Customer Registration Form

72
5 Create Account
6. Bill Reading Form

73
7. Change password Form
8. Bill Payment Form

74
9. Bill Reporting Form
10. Bill Recorded Form

75
5.3 Sample Implementation Algorism
To create account

76
5.4 SYSTEM TESTING

The development of Software System involves a series of production activities. There is
a chance of errors to occur at any stage. Because of human inability to perform and
communicate with perfection, a Quality Assurance Activity accompanies software
development. Software testing is a critical element of software quality assurance and
represents the ultimate review of specification, design and code generation. The
increasing visibility of software as a system element and the costs associated with
software failure are motivating forces for well planned, through testing. For testing the
system we followed the strategies given below
Testing Techniques:
 Different types of testing are

 Unit Test
 Ingenerated Testing
 Validation Testing

77
5.4.1 Unit Testing

During the implementation for the system each modules of the system was tested
separately to uncover errors which its boundaries. User interface was used as a guide in
this process. The validations have been done for all the inputs using Java Script. For
example to check whether the work allotted among the database correctly without
exceeding the schemes which are not validated thoroughly and the internal database has
to check the reflections in the database
5.4.2 Integration Test:

The objective of Integration Test is to take the until tested modules and build a program
structure that has been defined in the design. We have done top down integration, which is
constructing and testing small segments where errors are easier to isolate, and corrected
5.4.3 Validation Testing:

At the culmination of integration testing, software is completely assembled as a package,
interfacing errors have been uncovered and corrected, and a final series of software tests
namely validation tests are performed. Validation succeeds when the software functions
in the manner that can be easily accepted by the customer.

78
CHAPTER SIX
6 Conclusion and Recommendation
6.1 Conclusion
We have analyzed the existing system of Tepi town electric power service database management
system and proposed a new system that solves the difficulties related to the existing system. The
existing system is paper based, so 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 institution as a whole.
By analyzing existing system our aim was to build a new system that has greater functionality
that enhances effectiveness and efficiency.
To achieve our goal [to design new system] we have spent all of our 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, gathering requirement
and analysis.
The team has faced many challenges starting from the lab due to electric power loss, time, and in
the organization all of the employees were willing to cooperate/to provide as relevant
information as we needed.
Tepi Town Electric power service is one of the main organization that give services to people in
Tepi town. After we have completed the project we are sure the problems in the existing system
would overcome.
6.2 Recommendation
Since we are now living in a world that is led by technology and technology results, we need
more and more applications to familiarize ourselves and also come up with the fast advancing
technology.

79
The system that we have developed is a desktop application it needs a skilled person to work
with the system. So, we recommend the system should be entitled to the responsible and skilled
person. We highly recommend the system should be kept in highly safe and favorable condition.
To enable the institution to achieve its objectives, we recommend these
1. The institution has to implement this software in all of its branches
2. It should enhance its employees in to technology oriented environment [i.e. it should

provide the employees with short term computer training].
3. The institution should provide all the equipment required to get to the goal.

80
6.3 References
 Whitten Bentley Rittman, System Analysis and Design Methods, Tata McGraw Hill
Edition, 6th Edition.
 Software Engineering: a Practitioner's Approach, Roger S. Pressman, McGraw Hill
International, Fifth edition.
 Ambler, S. W. (June 22, 2001). The Object Primer:Introduction to Techniques for

Agile Modeling. In S. W. Ambler, Introduction to Techniques for Agile Modeling
(p. 29). Ronin International.
 http://www.google.com/project
 http://www.1000project.com/source
 The resources that we used in this project are listed below
 http://r16---sn-aigllnsr.googlevideo.com/videoplayback?ip
 http://www.csee.wvu.edu/~ammar/rts/Chapter7-Collaboration%20Diagram.pdf
 http://www.objectmentor.com/resources/articles/umlCollaborationDiagrams.pdf

81

Tepi Town Electric Power Billing System

Uploaded by

Document Information

Original Description:

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

Tepi Town Electric Power Billing System

Uploaded by

Copyright:

Available Formats

Mizan-Tepi University

School of Computing and Informatics

Degree of Bachelor of Science in Information Technology

TITLE: - TEPI-TOWN ELECTRIC POWER BILLING SYSTEM

Advisor: Mr. AdmasAbtew(Msc)

Date: 16/04/2007 E.C

Degree of Bachelor of Science in Information Technology

TITLE: - TEPI-TOWN ETECTRIC POWER BILLING SYSTEM

Name and signature of Members of the Examining Board

Name Signature Date

___________________________ ____________ ___________

___________________________ ____________ ___________

___________________________ ____________ ___________

___________________________ ____________ ___________

___________________________ ____________ ___________

___________________________ ____________ ___________

Name_____________________________ Signature_______________ Date__________

Name_____________________________ Signature_______________ Date__________

Name_____________________________ Signature_______________ Date__________

Name_____________________________ Signature_______________ Date__________

_______________________ _________________ ________________Advisor Name

VB……………Microsoft Visual Studio 2010 ENG-UPDATED-Team MYZ

MTU Information Technology Department 2015

1.3 Statement of the problem

 As everything is done manually its slow process

1.4 Scope of the project

MTU Information Technology Department 2015

Limitation is the thing that our system unable to perform because of

 when reader wants to read he/she going to each customers house

1.6 Objective of the project

1.6.2 Specific objective

 Study the existing system and find out the problem.

 Utilizes human and material resource efficiently.

1.7 Requirement gathering methodology

1.7.1 Data collection methodology:

1.7.1.2 Direct Observation

1.7.1.3 Reading documents

1.8 Need for feasibility study

The key consideration involve in the feasibility study are:

1.8.1 Assessing Technical feasibility

MTU Information Technology Department 2015

1.8.2 Assessing Operational feasibility

MTU Information Technology Department 2015

1.8.3 Assessing economic feasibility:-

1.9 Significant of the project

 Easy to use, effective and efficient

 Fast access and more secure.

1.10 Assessing time schedule feasibility

MTU Information Technology Department 2015

It is determining start and finish date for project activity.

1.10.1 Budget schedule

MTU Information Technology Department 2015

Development Technologies and Tools

MTU Information Technology Department 2015

1.8 Operating environment

Table 1 hardware and software

1.10.2 Risk assessment:-

MTU Information Technology Department 2015

1.10.3 Risk Mitigation:-

MTU Information Technology Department 2015

2 Analysis and Requirement Gathering

2.2 Existing system description

2.3 Business rules

_________________ _

_________________ _

_________________ _

_________________ _

_________________ _

_________________ _

Name_____________________ Signature_ Date____

Name_____________________ Signature_ Date____

Name_____________________ Signature_ Date____

Name_____________________ Signature_ Date____

_______________ _ ________Advisor Name

Contract No. _______________ A/CNo. _ Meter Book No. ____

Prepared by_______ Consumer's Signature _

Date _ Consumer's Division _____________

Inspection Division __ D ate