SEPM anshul

8/2/2019 SEPM anshul

1/32

ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH,

INDORE

(ONLINE ELECTRICITY BILLING SYSTEM)

A project report Submitted to

Rajiv Gandhi Proudyogiki Vishwavidyalaya, Bhopal

Towards partial fulfillment of

The Degree of

Bachelor of Engineering

In

Computer Science and Engineering

2011-2012

Acropolis Institute of Technology & Research, Indore (M.P.) Department ofComputer Science Engineering & Information Technology


2/32


INDORE

(Online Electricity Billing System)

A project report Submitted to

Rajiv Gandhi Proudyogiki Vishwavidyalaya, Bhopal

Towards partial fulfillment of

The Degree of

Bachelor of Engineering

In

Computer Science and Engineering

2011-2012

Guided by Submitted byEr. Kamlesh Panwar Anshul Gupta

Acropolis Institute of Technology & Research, Indore (M.P.)Department of Computer Science Engineering & Information Technology


3/32


INDORE

CERTIFICATE

This is to certify that Mr. Anshul Gupta (23), Mr. Gurdeep Yadav (39) & Mr. Manish Patel (57)

B.E. (Computer Science and Engineering) third year 2012 of Computer Science and Engineering

department of this Institute have completed the project work entitled Online Electricity Billing

System based on syllabus.

Professor & Head, CSE Guided By:

Prof. Sanjay Bansal Er. Kamlesh Panwar

Acropolis Institute of Technology & Research, Indore (M.P.)Department of Computer Science Engineering & Information Technology


4/32


INDORE

CERTIFICATE

This is to certify that the project work entitled Fingerprint Recognition System submitted by Mr.

Anshul Gupta (23), Mr. Gurdeep Yadav (39) & Mr. Manish Patel (58), B.E. (Computer Science and

Engineering ) third year in the year 2012 of Computer Science and Engineering Department of this

institute based on syllabus and is approved as partial fulfillment for the award of the Bachelor of

Engineering (in Computer Science and Engineering ) Degree by Rajiv Gandhi Proudyogiki

Vishwavidyalaya, Bhopal.

Internal Examiner External Examiner

Date: Date:


5/32

ACKNOWLEDGEMENT

There are two ways of spreading the light, to be a candle, or the mirror, which reflects it. In relation to

the light of knowledge o, this work carried out by us is just a mirror. There are some candles on the

other side of the mirror. We would like to avail this opportunity to express our sincere thanks to all those

who helped us in making this project. Even a most vivid collection of words, yield to express our heart

fully thank towards one and all to have successfully assisted us in our expenditure of carrying out this

project.

We wish to express our deep sense of gratitude to H.O.D Prof. Sanjay Bansal, our project coordinator

Ms. Kavita Namdev our project guide Er. Kamlesh Panwar and the whole faculty members of the

department of Computer Science for encouraging and giving moral support, not only regarding this

project but also throughout our studies at this institute. Also, to all my fellow classmates, friends and

well wishers for their support and cooperation towards us.

Anshul Gupta (23)

Gurdeep Yadav (39)

Manish Patel (57)


6/32

CONTENTS

Organization of Report Page No.

1. Abstract2. Introduction Objectives Scope Identification of problem in existing system platform specification

Hardware Requirements Software Requirements

3. System Requirement Analysis Information gathering System Feasibility

Technical Feasibility Economical Feasibility Behavioral Feasibility

4. System Analysis4.1 Data Dictionary

4.2 Use case modeling

4.2.1 Use case model

4.2.2 Use case specifications

4.3 Information flow representation

4.3.1 Sequence Diagrams

4.3.2 class diagram

4.3.3 state chart diagram

4.3.4. data dictionary5. Design5.1 Architectural

5.1.1 Architectural Context Diagram

5.1.2 Architectural Behavioral Diagram

5.1.3 Description of Architectural Diagram

5.1.4 Control Hierarchy


7/32

Object Oriented Approacho Modules Usedo Internal Data Structureso Algorithm design for operationso Data design

Interface Designo Human-machine interface design specificationo I/O formso Reports

6. Testing Objective Scope Principles Methods Test Cases Sample Test Data and Results

Limitations Future Scope Conclusion References Appendix


8/32

1.Abstract:

Beginning with Benjamin Franklin's experiment with a kite, one stormy night in Philadelphia, the

principles of electricity gradually evolved. In the mid-1800s, everyone's life changed with the invention

of the electric light bulb. Thomas Edison improved the 1st electric bulb in 1879 and was able to

produce a reliable, long-lasting source of light. Since then, providing electricity has become the basic

means of living. This important facility is thus managed by the government established company

M.P.S.E.B (Madhya Pradesh State Electricity Board).Population is increasing and new houses are being

constructed, there by leading to new electrical connections. Manually maintaining the records is quite

difficult and there comes the usage of computers, invented by Charles Babbage which has proved to

be a boon in the current world. Starting w ith the Analytical Engine, much advancement has been

done to the computer system. Now-a-days, computers are used everywhere. This usage of computers

in M.P.S.E.B has reduced the work load, increased efficiency and reliability.

Our project basically deals with developing an web application for OEBS ( Online Electricity

Billing System).The Online Electricity Billing System provides consumer an easy way to pay their billsand complaints. This will help the user and as well as the organization.


9/32

2.Introduction:

Objective:

The purpose of this application is to develop OEBS (Electronic Billing System), which is a web

application which provides a service to all the customers and employees of M.P.S.E.B to deal with the

transactions online.

The main purpose of these application is to provide facility of Online billing for consumers. This will

help in reducing the time and effort required to pay the bills, which is beneficial for the consumer.

The organization will also be benefited by reduction in paper work and also less chances of errors since

all the records are handled automatically as compared to manual records where chances of errors are

high.

Scope:

This application is basically written as a solution to the drawbacks of existing system. This application can be

used as a real world application and by any organization. Its could be used as a general application with few

minor modifications.

Problems in Existing System:

In this modern era time is the most precious thing for each and every human being. Everybody wants

to complete their work effectively with less time and with less effort.

While paying bills we have to stand for long time in long queue and waits for our turn to come which

consumes our time. It sometime creates irritation to our mind. And another major problem is wastage

of large amount of paper fo [printing lakh of bills.

And also In the traditional system files were used to maintain the database which was done manually. This

existing system consumes a lot of time. This time consuming evaluation coupled by the huge maintenance

problem and may also lead to erroneous results. The various operations performed on these files like sorting,

adding, modifying and deletion of the records are very tedious. Moreover these manually maintained files have

the possibility of getting worn out. Thus, less durability is achieved.


10/32

Platform Specification:

Hardware Requirement:

Processor: Pentium 3 or higher

RAM: 256 MB or higher

Hard disk: minimum 250MB of free space

Software Requirement:

Operating system: Windows Xp / windows 7

Microsoft Visual Studio 2005 or higher

Microsoft Dot Net framework 2.0 or higher

Microsoft SQL server


11/32

3.System Requirement Analysis:

Information Gathering:Information gathering requires locating and integrating data from a set of distributedinformation sources. These sources may contain overlapping data and can come from

different types of sources, including traditional databases, knowledge bases, programs and

web pages. In our case the requirement of the project was very clear.

System Feasibility:

Technological Feasibility:

Technical feasibility centers on the existing computer system (hardware, Software, etc.) and to what

extent it can support the proposed addition. For example, if the current computer is operating at 80

percent capacity-an arbitrary ceiling-then running another application could overload the system or

require additional hardware. This involves financial considerations to accommodate technical

enhancements.

Economical Feasibility:

Economic analysis is the most frequently used method for evaluating the effectiveness of a candidate

system. More commonly known as cost/benefit analysis, the procedure is to determine the benefits

and savings that are expected from a candidate system and compare them with costs. If benefits

outweigh costs, then the decision is made to design and implement the system. Otherwise, further

justification or alterations in the proposed system will have to be made if it is to have a chance of being

approved. This is an ongoing effort that improves in accuracy at each phase of the system life cycle.


12/32

Behavioral Feasibility:

Purpose projects are beneficial only if they can be turned into information systems that will meet the

organizations operating systems.

Some of the conditions are :

Is there sufficient support for the project from management and users?

Are correct business methods acceptable to the users?

Have the users been involved in the planning and development of the project.

Will the proposed system cause harm?


13/32

3.SYSTEM ANALYSIS:

Data Dictionary:

A data dictionary is a structured repository of the data about the data. It specifies the data

that is used by the system. This section demonstrates the data dictionary which is

required to support our analysis models.

Use case modeling:

The use case model provides detailed information about the behaviors of the system or

application that you are developing. It contains use case diagrams and the activity

diagrams that describes how users interact with the system.

The use case model identifies the requirements of the system in terms of the functionality

that must exist to achieve the goals set out by the user or to solve a

problem identified by the user. Uses cases describe the major behaviors that you identify

in the requirements and describe the value that the results give the users

they do not describe how the system operates internally. Actors are the users of the

system and represent the different roles that people and other system play when they

interact with the system.

Use case diagrams depict the relationships between the uses cases and actors and activity

diagrams to describe the flow of objects and controls in each identified behaviors.

The use Case Model for our project along with the description of is as follows:


14/32

Use case model :

Bill Detail

Bill generate

Pay Bill

Complain Add

User Complain

Customer Registration

Bill Generate

Login

Admin

customer

Pay Bill

Bill Detail

Complain Add

Login

Customer Regis tration

Bill Generate

User Complain


15/32

Use case specification:

User:

Log in:

Every registered user is required to log in to use the facilities provided by the system. Every user is

provided with a user-name and password to access the system. The user as to enter the user-name and

password to log in into the system.

Pay bill:

After log in the user can pay the bill according to his choice. This facility helps him in reducing the time

and effort to pay the electricity bill.

Bill detail:

The user can view the details of the anytime he required. This also helps in proper maintining of the

records which is beneficial for both the user and the organization.

Add Complain:

The registered user after log in can lodge his complaints regarding the organization, staff and any

problem related to the bill etc. to the organization which are handled frequently by the admin.

Admin:

Log in:

The admin(administrator) is also provided with a username and password. After log in the Admin

homepage will be displayed having the different required functions.

Customer registration:

The admin has the authority to register new customers. A new customer want to register with the

organization then he has to register providing his details to the organization, after that the admin has toprovide approval for registering the new user.


16/32

User Complain:

The admin is responsible for handling the user complain. The admin handled the complains lodge by

user as per the complain.

Bill Generate:

The admin is the person who generates the bills of the users according to the usage of electricity as

shown in the meter readings by the linemans.


17/32

Information flow representation:

Sequence diagram:


18/32

Data Dictionary:

Column Name Data Type Constraints

meterno Varchar(50) Not nullName Varchar(50) Not nullAmount Nvarchar(50) Not nullcomplainno int Not nullcomplain Varchar(MAX) Allow nulls

email Varchar(50) Allow Nullcontact Varchar(50) Allow nulladdress Varchar(50) Allow Nulllname Varchar(50) Not null

fname Varchar(50) Not nullContactno. Varchar(50) Allow nulls

occupation Varchar(50) Allow nullsrole Varchar(50) Allow nulls

status Varchar(50) Allow nulls

sno int Not null

suggestion Varchar(50) Allow nulls


19/32

5. Architecture:

Architecture Context Diagram:

View Bill Detail

Bill generate

User Complain

Bill Payment

Add Complain

Log in

Add user

User

Admin

Data Base


20/32

Description of Architectural Diagram:

The architectural design defines the relationship between major structural elements of the

Online Electricity Billing System, the design patterns that can be used to achieve the

requirements that have been defined for the system, and the constraint that affect the way in

which architectural design patterns can be applied. The architectural design representation, the

framework, OIP can be derived from system specification, the analysis model, and the

interaction of subsystem defines within the analysis model.

The architectural design of a 3-tier client/server system is often characterized as a

communicating processes style describing architecture in the following way:

The goal is to achieve the quality of scalability. Online Electricity Billing System helps in

paying bills online which reduces the both time and effort. This also helps in reducing the data

inconsistency in the system which is beneficial for both the user and the organization.


21/32

Object Oriented Approach:

Object oriented analysis and design is a software engineering approach that models a

system as a group of interacting objects. Each object represents some entity interest in the

system being modeled and is characterized by its class, its static elements , and its

deployment of this collaborating objects there are number of different notation for

representing these modules, such as the unified modeling language.

Object oriented analysis applies object modeling techniques to analysis the function

required for a system. Object oriented design elaborates the analysis models to produce

implementation specification. Object oriented analysis focuses on what system does.

Data design:

The data design creates the model of data and information i.e. representation at a high

level of abstraction. The data object define during software requirements analysis aremodeled using ER diagram and data dictionary. The data design activity translates these

elements of requirement model into data structure at component data level.

Interface design:

Human-machine interface design specification:

The interface design is a bridge for interaction between a human and a computer. It create

an effective communication between the human and the computer. The interface design

begins with the identification of the user, task and environmental requirements. It is the

information representation of the available data thus, if the representation is confusing or

misleading user may misunderstand the meaning of the information. The best possible

representation of the data or the easiest interface is the Graphical user interface (GUI).

The GUI provides us with windows, icons, menus and pointer etc.

Interface Design focus on the following area of concern:

1. The design of interface between software modules.

2. The design of interface between user and the computer.


22/32

I/O Forms:

Login page


23/32

User Homepage


24/32

Admin Homepage


25/32

6.TESTING :

The development of software systems involves a series of production activities where

opportunities for injection of human fallibilities are enormous. Errors may begin to occur at the

very inception of the process where the objectives . . . may be erroneously or imperfectly

specified, as well as [in] later design and development stages . . .Because of human inability to

perform and communicate with perfection, software development is accompanied by a quality

assurance activity.

Testing Objectives :

In an excellent book on software testing, Glen Myers [MYE79] states a number of

rules that can serve well as testing objectives:

1. Testing is a process of executing a program with the intent of finding an

error.

2. A good test case is one that has a high probability of finding an as-yetundiscovered

error.

3. A successful test is one that uncovers an as-yet-undiscovered error.

These objectives imply a dramatic change in viewpoint. They move counter to the commonly

held view that a successful test is one in which no errors are found. Objective is to design tests

that systematically uncover different classes of errors and to do so with a minimum amount of

time.

If testing is conducted successfully (according to the objectives stated previously), it will

uncover errors in the software. As a secondary benefit, testing demonstrates that software

functions appear to be working according to specification, that behavioral and performancerequirements appear to have been met. In addition, data collected as testing is conducted provide

a good indication of software reliability and some indication of software quality as a whole. But

testing cannot show the absence of errors and defects, it can show only that software errors and

defects are present. It is important to keep this (rather gloomy) statement in mind as testing is

being conducted.

Scope of Testing :


26/32


27/32

Software testing methods are traditionally divided into white- and black-box testing. These two

approaches are used to describe the point of view that a test engineer takes when designing test

cases.

White-box testing :

White-box testing is when the tester has access to the internal data structures and algorithms

including the code that implements these.

Types of white-box testing

The following types of white-box testing exist:

API testing (application programming interface) - testing of the application usingpublic and private APIs

Code coverage- creating tests to satisfy some criteria of code coverage (e.g., the testdesigner can create tests to cause all statements in the program to be executed at

least once)

Fault injectionmethods - improving the coverage of a test by introducing faults totest code paths

Mutation testingmethods

Static testing- All types

Test coverage

White-box testing methods can also be used to evaluate the completeness of a test suite

that was created with black-box testing methods. This allows the software team to

examine parts of a system that are rarely tested and ensures that the most important

function pointshave been tested.[21]

Two common forms of code coverage are:

Function coverage, which reports on functions executed Statement coverage, which reports on the number of lines executed to complete

the test

They both return acode coveragemetric, measured as apercentage.
http://en.wikipedia.org/wiki/Application_programming_interfacehttp://en.wikipedia.org/wiki/Application_programming_interfacehttp://en.wikipedia.org/wiki/Code_coveragehttp://en.wikipedia.org/wiki/Code_coveragehttp://en.wikipedia.org/wiki/Fault_injectionhttp://en.wikipedia.org/wiki/Fault_injectionhttp://en.wikipedia.org/wiki/Mutation_testinghttp://en.wikipedia.org/wiki/Mutation_testinghttp://en.wikipedia.org/wiki/Static_testinghttp://en.wikipedia.org/wiki/Static_testinghttp://en.wikipedia.org/wiki/Function_pointshttp://en.wikipedia.org/wiki/Function_pointshttp://en.wikipedia.org/wiki/Software_testing#cite_note-20http://en.wikipedia.org/wiki/Software_testing#cite_note-20http://en.wikipedia.org/wiki/Software_testing#cite_note-20http://en.wikipedia.org/wiki/Code_coveragehttp://en.wikipedia.org/wiki/Code_coveragehttp://en.wikipedia.org/wiki/Software_metrichttp://en.wikipedia.org/wiki/Software_metrichttp://en.wikipedia.org/wiki/Software_metrichttp://en.wikipedia.org/wiki/Percentagehttp://en.wikipedia.org/wiki/Percentagehttp://en.wikipedia.org/wiki/Percentagehttp://en.wikipedia.org/wiki/Percentagehttp://en.wikipedia.org/wiki/Software_metrichttp://en.wikipedia.org/wiki/Code_coveragehttp://en.wikipedia.org/wiki/Software_testing#cite_note-20http://en.wikipedia.org/wiki/Function_pointshttp://en.wikipedia.org/wiki/Static_testinghttp://en.wikipedia.org/wiki/Mutation_testinghttp://en.wikipedia.org/wiki/Fault_injectionhttp://en.wikipedia.org/wiki/Code_coveragehttp://en.wikipedia.org/wiki/Application_programming_interface


28/32

Black Box Testing :

Black-box testing treats the software as a "black box"without any knowledge of internal

implementation. Black-box testing methods include: equivalence partitioning, boundary value

analysis, all-pairs testing, fuzz testing, model-based testing, exploratory testing and specification-

based testing.

Advantages and disadvantages:

The black-box tester has no "bonds" with the code, and a tester's perception is verysimple: a code must have bugs. Using the principle, "Ask and you shall receive," black-

box testers find bugs where programmers do not. On the other hand, black-box testing

has been said to be "like a walk in a dark labyrinth without a flashlight," because the

tester doesn't know how the software being tested was actually constructed. As a result,

there are situations when (1) a tester writes many test cases to check something that could

have been tested by only one test case, and/or (2) some parts of the back-end are not

tested at all.

Therefore, black-box testing has the advantage of "an unaffiliated opinion", on the one hand,and the disadvantage of "blind exploring", on the other.

Grey Box Testing:

Grey-box testing(American spelling: gray-box testing) involves having knowledge of internal

data structures and algorithms for purposes of designing tests, while executing those tests at the

user, or black-box level. The tester is not required to have full access to the software's source

code. Manipulating input data and formatting output do not qualify as grey-box, because the

input and output are clearly outside of the "black box" that we are calling the system under test.This distinction is particularly important when conducting integration testing between two

modules of code written by two different developers, where only the interfaces are exposed for

test. However, modifying a data repository does qualify as grey-box, as the user would not

normally be able to change the data outside of the system under test. Grey-box testing may also

includereverse engineeringto determine, for instance, boundary values or error messages.
http://en.wikipedia.org/wiki/Equivalence_partitioninghttp://en.wikipedia.org/wiki/Equivalence_partitioninghttp://en.wikipedia.org/wiki/Boundary_value_analysishttp://en.wikipedia.org/wiki/Boundary_value_analysishttp://en.wikipedia.org/wiki/Boundary_value_analysishttp://en.wikipedia.org/wiki/All-pairs_testinghttp://en.wikipedia.org/wiki/All-pairs_testinghttp://en.wikipedia.org/wiki/Fuzz_testinghttp://en.wikipedia.org/wiki/Fuzz_testinghttp://en.wikipedia.org/wiki/Model-based_testinghttp://en.wikipedia.org/wiki/Model-based_testinghttp://en.wikipedia.org/wiki/Exploratory_testinghttp://en.wikipedia.org/wiki/Exploratory_testinghttp://en.wikipedia.org/wiki/Gray_box_testinghttp://en.wikipedia.org/wiki/Gray_box_testinghttp://en.wikipedia.org/wiki/Integration_testinghttp://en.wikipedia.org/wiki/Integration_testinghttp://en.wikipedia.org/wiki/Reverse_codinghttp://en.wikipedia.org/wiki/Reverse_codinghttp://en.wikipedia.org/wiki/Reverse_codinghttp://en.wikipedia.org/wiki/Reverse_codinghttp://en.wikipedia.org/wiki/Integration_testinghttp://en.wikipedia.org/wiki/Gray_box_testinghttp://en.wikipedia.org/wiki/Exploratory_testinghttp://en.wikipedia.org/wiki/Model-based_testinghttp://en.wikipedia.org/wiki/Fuzz_testinghttp://en.wikipedia.org/wiki/All-pairs_testinghttp://en.wikipedia.org/wiki/Boundary_value_analysishttp://en.wikipedia.org/wiki/Boundary_value_analysishttp://en.wikipedia.org/wiki/Equivalence_partitioning


29/32

By knowing the underlying concepts of how the software works, the tester makes better-

informed testing choices while testing the software from outside. Typically, a grey-box tester

will be permitted to set up his testing environment; for instance, seeding a database; and the

tester can observe the state of the product being tested after performing certain actions. For

instance, in testing a database product he/she may fire an SQLquery on the database and then

observe the database, to ensure that the expected changes have been reflected. Grey-box testingimplements intelligent test scenarios, based on limited information. This will particularly apply

to data type handling, exception handling, and so on.

Visual Testing :

The aim of visual testing is to provide developers with the ability to examine what washappening at the point of software failure by presenting the data in such a way that the developer

can easily find the information he requires, and the information is expressed clearly.

At the core of visual testing is the idea that showing someone a problem (or a test failure), rather

than just describing it, greatly increases clarity and understanding. Visual testing therefore

requires the recording of the entire test process capturing everything that occurs on the test

system in video format. Output videos are supplemented by real-time tester input via picture-in-

a-picture webcam and audio commentary from microphones.

Visual testing provides a number of advantages. The quality of communication is increased

dramatically because testers can show the problem (and the events leading up to it) to the

developer as opposed to just describing it and the need to replicate test failures will cease to

exist in many cases. The developer will have all the evidence he requires of a test failure and can

instead focus on the cause of the fault and how it should be fixed.

Ad hoc testing and exploratory testing are important methodologies for checking software

integrity, because they require less preparation time to implement, whilst important bugs can be

found quickly. In ad hoc testing, where testing takes place in an improvised, impromptu way,

the ability of a test tool to visually record everything that occurs on a system becomes very

important.

Visual testing is gathering recognition in customer acceptance and usability testing, because the

test can be used by many individuals involved in the development process.For the customer, it

becomes easy to provide detailed bug reports and feedback, and for program users, visual testing

can record user actions on screen, as well as their voice and image, to provide a complete picture

at the time of software failure for the developer.
http://en.wikipedia.org/wiki/Databasehttp://en.wikipedia.org/wiki/Databasehttp://en.wikipedia.org/wiki/SQLhttp://en.wikipedia.org/wiki/SQLhttp://en.wikipedia.org/wiki/Ad_hoc_testinghttp://en.wikipedia.org/wiki/Ad_hoc_testinghttp://en.wikipedia.org/wiki/Exploratory_testinghttp://en.wikipedia.org/wiki/Exploratory_testinghttp://en.wikipedia.org/wiki/Acceptance_testing#customer_acceptancehttp://en.wikipedia.org/wiki/Acceptance_testing#customer_acceptancehttp://en.wikipedia.org/wiki/Usability_testinghttp://en.wikipedia.org/wiki/Usability_testinghttp://en.wikipedia.org/wiki/Usability_testinghttp://en.wikipedia.org/wiki/Acceptance_testing#customer_acceptancehttp://en.wikipedia.org/wiki/Exploratory_testinghttp://en.wikipedia.org/wiki/Ad_hoc_testinghttp://en.wikipedia.org/wiki/SQLhttp://en.wikipedia.org/wiki/Database


30/32

Test Cases in Software Testing :

A test case in software engineering is a set of conditions or variables under which a tester will

determine whether anapplicationorsoftware systemis working correctly or not. The mechanism for

determining whether a software program or system has passed or failed such a test is known as a

test oracle. In some settings, an oracle could be arequirementoruse case, while in others it could be

a heuristic. It may take many test cases to determine that a software program or system is

considered sufficiently scrutinized to be released. Test cases are often referred to as test scripts,

particularly when written. Written test cases are usually collected intotest suites.

Formal test cases :

In order to fully test that all the requirements of an application are met, there must be at least

two test cases for each requirement: one positive test and one negative test. If a requirement has

sub-requirements, each sub-requirement must have at least two test cases. Keeping track of thelink between the requirement and the test is frequently done using a traceability matrix. Written

test cases should include a description of the functionality to be tested, and the preparation

required to ensure that the test can be conducted.

A formal written test-case is characterized by a known input and by an expected output, which is

worked out before the test is executed. The known input should test a precondition and the

expected output should test apostcondition.

InFormal test cases :

For applications or systems without formal requirements, test cases can be written based on the

accepted normal operation of programs of a similar class. In some schools of testing, test cases

are not written at all but the activities and results are reported after the tests have been run.

In scenario testing, hypothetical stories are used to help the tester think through a complex

problem or system. These scenarios are usually not written down in any detail. They can be as

simple as a diagram for a testing environment or they could be a description written in prose.

The ideal scenario test is a story that is motivating, credible, complex, and easy to evaluate.

They are usually different from test cases in that test cases are single steps while scenarios covera number of steps of the key.
http://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_applicationhttp://en.wikipedia.org/wiki/Software_applicationhttp://en.wikipedia.org/wiki/Software_applicationhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Oracle_%28software_testing%29http://en.wikipedia.org/wiki/Oracle_%28software_testing%29http://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Heuristichttp://en.wikipedia.org/wiki/Heuristichttp://en.wikipedia.org/wiki/Test_scripthttp://en.wikipedia.org/wiki/Test_scripthttp://en.wikipedia.org/wiki/Test_suitehttp://en.wikipedia.org/wiki/Test_suitehttp://en.wikipedia.org/wiki/Test_suitehttp://en.wikipedia.org/wiki/Traceability_matrixhttp://en.wikipedia.org/wiki/Traceability_matrixhttp://en.wikipedia.org/wiki/Preconditionhttp://en.wikipedia.org/wiki/Preconditionhttp://en.wikipedia.org/wiki/Postconditionhttp://en.wikipedia.org/wiki/Postconditionhttp://en.wikipedia.org/wiki/Postconditionhttp://en.wikipedia.org/wiki/Scenario_testinghttp://en.wikipedia.org/wiki/Scenario_testinghttp://en.wikipedia.org/wiki/Scenario_testinghttp://en.wikipedia.org/wiki/Postconditionhttp://en.wikipedia.org/wiki/Preconditionhttp://en.wikipedia.org/wiki/Traceability_matrixhttp://en.wikipedia.org/wiki/Test_suitehttp://en.wikipedia.org/wiki/Test_scripthttp://en.wikipedia.org/wiki/Heuristichttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Oracle_%28software_testing%29http://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_applicationhttp://en.wikipedia.org/wiki/Software_engineering


31/32

Limitations:

The current system is only used for billing payment and complain. It does not include options like

revenue collection, due bills etc.

The current system uses payment only through credit cards.

Future Enhancement:

In future we will work for providing READING CAPTURE DEVICE(RCD), which is attached with

every meter and send usage reading on a fixed date of every month, to the MPEB office and accordingto that the bill will sent to the e-mail addresss of the customer and they can pay their bill online which

reduces the effort of a lineman who has to go every home for collecting the reading of the meter, thisalso saves time.

Another feature of RCD is to stop and reduce Power Theft.

Other enhancement is providing SMS facility by which SMS sent to the customer mobile number by the

electric board about his meter reading, amount of bill, last date of paying bill, and also the amount paid

by the customer with date type of paying.

Conlusion:

This project is very easy to install and easy to access for the customers. By anytime and online payment

of electricity bills their lots of time and efforts will save. They get their bill directly on their e- mail idand on mobile also at every fixed date of every month. They also do not have to bother about the

delivery of bill. They do not have to stand in a long queue for the payment of bills and they can also

view their billing information anytime.


32/32

Reference:

To develop this project we are taking the guidance of our seniors, faculty members and friends.

We also took some information from the electricity office.

Refernces are:

Electricity officeElectricity Exchange

Electricity bill

Web sites:

www.google.com

www.mpeb.co.in

www.wikipedia.com
http://www.google.com/http://www.google.com/http://www.mpeb.co.in/http://www.mpeb.co.in/http://www.mpeb.co.in/http://www.google.com/

SEPM anshul

Documents

Transcript of SEPM anshul