Professional Documents
Culture Documents
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.
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.
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.
CONTENTS
Organization of Report 1. Abstract 2. Introduction Objectives Scope Identification of problem in existing system platform specification Hardware Requirements Software Requirements Page No.
3. System Requirement Analysis Information gathering System Feasibility Technical Feasibility Economical Feasibility Behavioral Feasibility 4. System Analysis 4.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 dictionary 5. Design 5.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
Object Oriented Approach o Modules Used o Internal Data Structures o Algorithm design for operations o Data design Interface Design o Human-machine interface design specification o I/O forms o Reports 6. Testing Objective Scope Principles Methods Test Cases Sample Test Data and Results Limitations Future Scope Conclusion References Appendix
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 with 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 bills and complaints. This will help the user and as well as the organization.
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.
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
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.
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?
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.
Login Login
Admin
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 to provide approval for registering the new user.
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.
Data Dictionary:
Column Name meterno Name Amount complainno complain email contact address lname fname Contactno. occupation role status sno suggestion Data Type Varchar(50) Varchar(50) Nvarchar(50) int Varchar(MAX) Varchar(50) Varchar(50) Varchar(50) Varchar(50) Varchar(50) Varchar(50) Varchar(50) Varchar(50) Varchar(50) int Varchar(50) Constraints Not null Not null Not null Not null Allow nulls Allow Null Allow null Allow Null Not null Not null Allow nulls Allow nulls Allow nulls Allow nulls Not null Allow nulls
5. Architecture:
Architecture Context Diagram:
Log in
Bill generate
Add Complain
Data Base
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.
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 are modeled 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.
I/O Forms:
Login page
User Homepage
Admin Homepage
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 performance requirements 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 :
A primary purpose of testing is to detect software failures so that defects may be discovered and corrected. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions. The scope of software testing often includes examination of code as well as execution of that code in various environments and conditions as well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do. In the current culture of software development, a testing organization may be separate from the development team. There are various roles for testing team members. Information derived from software testing may be used to correct the process by which software is developed.
Principles of Testing :
Before applying methods to design effective test cases, a software engineer must understand the basic principles that guide software testing. Davis [DAV95] suggests a set1 of testing principles that have been adapted for use in this book: All tests should be traceable to customer requirements. As we have seen, the objective of software testing is to uncover errors. It follows that the most severe defects (from the customers point of view) are those that cause the program to fail to meet its requirements. Tests should be planned long before testing begins. Test planning can begin as soon as the requirements model is complete. Detailed definition of test cases can begin as soon as the design model has been solidified. Therefore, all tests can be planned and designed before any code has been generated. The Pareto principle applies to software testing. Stated simply, the Pareto principle implies that 80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all program components. The problem,of course, is to isolate these suspect components and to thoroughly test them. Testing should begin in the small and progress toward testing in the large. The first tests planned and executed generally focus on individual components. As testing progresses, focus shifts in an attempt to find errors in integrated clusters of components and ultimately in the entire system.
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.
public and private APIs Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the test designer can create tests to cause all statements in the program to be executed at least once) Fault injection methods - improving the coverage of a test by introducing faults to test code paths Mutation testing methods 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 points have 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
Advantages and disadvantages: The black-box tester has no "bonds" with the code, and a tester's perception is very simple: a code must have bugs. Using the principle, "Ask and you shall receive," blackbox 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.
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 include reverse engineering to determine, for instance, boundary values or error messages.
By knowing the underlying concepts of how the software works, the tester makes betterinformed 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 SQL query on the database and then observe the database, to ensure that the expected changes have been reflected. Grey-box testing implements 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 was happening at the point of software failure by presenting the data in such a way that the developer can easily nd 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-ina-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.
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 cover a number of steps of the key.
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 according to 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, this also 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 id and 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.
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 office Electricity Exchange Electricity bill Web sites: www.google.com www.mpeb.co.in www.wikipedia.com