SEPM anshul
-
Upload
anshul-gupta -
Category
Documents
-
view
229 -
download
0
Transcript of 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
-
8/2/2019 SEPM anshul
2/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
Guided by Submitted byEr. Kamlesh Panwar Anshul Gupta
Acropolis Institute of Technology & Research, Indore (M.P.)Department of Computer Science Engineering & Information Technology
-
8/2/2019 SEPM anshul
3/32
ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH,
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
-
8/2/2019 SEPM anshul
4/32
ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH,
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:
-
8/2/2019 SEPM anshul
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)
-
8/2/2019 SEPM anshul
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
-
8/2/2019 SEPM anshul
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/2/2019 SEPM anshul
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.
-
8/2/2019 SEPM anshul
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.
-
8/2/2019 SEPM anshul
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
-
8/2/2019 SEPM anshul
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.
-
8/2/2019 SEPM anshul
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?
-
8/2/2019 SEPM anshul
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:
-
8/2/2019 SEPM anshul
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
-
8/2/2019 SEPM anshul
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.
-
8/2/2019 SEPM anshul
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.
-
8/2/2019 SEPM anshul
17/32
Information flow representation:
Sequence diagram:
-
8/2/2019 SEPM anshul
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
-
8/2/2019 SEPM anshul
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
-
8/2/2019 SEPM anshul
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.
-
8/2/2019 SEPM anshul
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.
-
8/2/2019 SEPM anshul
22/32
I/O Forms:
Login page
-
8/2/2019 SEPM anshul
23/32
User Homepage
-
8/2/2019 SEPM anshul
24/32
Admin Homepage
-
8/2/2019 SEPM anshul
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 :
-
8/2/2019 SEPM anshul
26/32
-
8/2/2019 SEPM anshul
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 -
8/2/2019 SEPM anshul
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 -
8/2/2019 SEPM anshul
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 -
8/2/2019 SEPM anshul
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 -
8/2/2019 SEPM anshul
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.
-
8/2/2019 SEPM anshul
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/