UNIVERSITY OF SCIENCE & TECHNOLOGY

MEGHALAYA

MAJOR PROJECT (2018 – 2021)

UNDER

ASSAM POWER DISTRIBUTION COMPANY LIMITED

BIJULEE BHAWAN, GUWAHATI – 781001

TOPIC – STANDARD OF PERFORMANCE (SOP)

External Guide:
Reza Mahmud, AGM (Systems), APDCL

Internal Guide:
Sangeeta Borkakoty, Asst. Prof., Dept. of Computer Science &
Electronics

Submitted By
Debojit Medhi
2018/BCA/0022
Sixth Semester
Bachelor of Computer Application
Department of Computer Science & Electronics
 UNIVERSITY OF SCIENE & TECHNOLOGY
MEGHALAYA
(Established under Act 6 of 2008 enacted by the state Legislative Assembly of
Meghalaya & incorporated under section 22 & 2(f) of the UGC Act 1956)

Date: 11th August, 2021

CERTIFICATE
This is to certify that Mr. Debojit Medhi have prepared and submitted the
dissertation report entitled “STANDARD OF PERFORMANCE”. This work was
done under the supervision & guidance of Reza Mahmud (External Guide) & Mrs.
Sangeeta Borkakoty (Internal Guide).

The dissertation is the result of their efforts & endeavors. The dissertation is found
worthy of acceptance for the partial fulfillment of Bachelor of Computer
Application (BCA).

Dr. Bhairab Sarma

Head, Dept. of Computer Sc. & Electronics
University of Science & Technology Meghalaya

Place: Meghalaya

Date: 11th August, 2021

Techno City, Kling Road, Baridua, 9th Mile, Ri-Bhoi, Meghalaya – 793101
Ph: 0361-2895030 (Telefax), 098540-23060, E-mail: ustm2011@gmail.com, Website: www.ustm.ac.in
 UNIVERSITY OF SCIENE & TECHNOLOGY
MEGHALAYA
(Established under Act 6 of 2008 enacted by the state Legislative Assembly of
Meghalaya & incorporated under section 22 & 2(f) of the UGC Act 1956)

Date: 11th August, 2021

CERTIFICATE

This is to certify that Mr. Debojit Medhi, student of BCA 6th semester bearing
Enrolment number: UG/2018/1745 has completed his project work entitled
“STANDARD OF PERFORMANCE” submitted in partial fulfillment of the major
project of Bachelor of Computer Application, 6th semester of the University of
Science and Technology, Meghalaya.

This work has been done under my supervision & guidance within the semester.
During the period of his association with me, I found her performance to be excellent.

The dissertation is found worthy of acceptance for the partial fulfillment of Bachelor
of Computer Application (BCA).

Mrs. Sangeeta Borkakoty

Asst. Professor & Internal Guide
University of Science & Technology Meghalaya

Place: Meghalaya

Date: 11th August, 2021

Techno City, Kling Road, Baridua, 9th Mile, Ri-Bhoi, Meghalaya – 793101
Ph: 0361-2895030 (Telefax), 098540-23060, E-mail: ustm2011@gmail.com, Website: www.ustm.ac.in
 DECLARATION

I, Debojit Medhi bearing University Roll No 2018/BCA/0022 of BCA 6th Semester

student of Department of Computer Science & Electronics, University of Science &
Technology, Meghalaya under the guidance of Ma’am Sangeeta Borkakoty declare
that the project entitled “STANDARD OF PERFORMANCE” done at Assam
Power Distribution Company Limited in fulfillment for the requirement of the Degree
of Bachelor of Computer Application (BCA) is my original work and it has not been
previously formed the basis for the award of any degree, diploma, fellowship or any
other qualification.

DEBOJIT MEDHI

2018/BCA/0022

DEPARTMENT OF COMPUTER SCIENCE & ELECTRONICS

 ACKNOWLEDGEMENT

It is with great pleasure that I found myself in penning down the lines to express my
sincere thanks to various people who helped us in the completion of this project.

This project would not have been possible without the guidance and the help of
several individuals who in way or another contributed and extended their valuable
assistance in the preparation and completion of this study.

I sincerely acknowledge the active guidance and help provided to me by my guide

Reza Mahmud.

I am very much thankful for the proper guidance and immense help provided in the
process of my project work.

I would like to convey my heartfelt gratitude to my internal guide Sangeeta Borkakoty

for her help and support during my project.

Also, I would like to express my gratitude to all my teachers for their help and timely
advice. Finally, thanks to all my friends in the department for their kind cooperation
and help inside as well as outside the computer centre.
 ABSTRACT
1. Title of the Project
2. Aim of the Project
3. Organization
4. Purpose
5. Duration
6. Project Done By
7. Software Used
8. Hardware Used
“STANDARD OF PERFORMANCE”
Sop is a report to show the efficiency of
the “Feeder(s)”, commonly known as
Electricity Lines.
With the help of these reports one can
easily come to know which feeder is not
working properly and needs
maintenance.
Assam Power Distribution Company
Limited
6th Semester Major Project, required for
the partial fulfilment of the award of
degree of Bachelor of Computer
Application (BCA) at University of
Science & Technology, Meghalaya
6 Months approx.
DEBOJIT MEDHI
Front – end : HTML, JavaScript, CSS
Back – end: MySQL Server 10.4.19
IDE : NetBeans 11.3
Web server : Apache
Server – side scripting: PHP 7.4.10
Operating System : Windows 10 Pro
System Type : 64-bit Operating System,
x64- based processor
Processor : Intel® Core™ i5-8250 CPU
Installed Memory (RAM): 4.00GB Hard
Drive (ROM) : 1TB
 TABLE OF CONTENTS
CHAPTER NO TITLE PAGE NO.

1. Introduction
1.1 Overview of the System 1
1.2 Problem Statement 2
1.3 Proposed System 3
1.4 Objectives 4
2. Requirement Specification 5-8
2.1 Tools & Technology Used 9
2.2 Feasibility Study 10 - 11
3. System Design 12
3.1 Structure Chart 13
3.2 Module Description 14
3.3 Data flow Diagram 15 - 16
- Context Diagram 17
- 1st Level DFD 18
3.4 E – R Diagram 19 - 20
3.5 Data Dictionary 21 - 23
3.6 Table Structure 24 - 25
4. Testing &Implementation 26 - 35
5. Documentation & User Manual 36 - 49
6. Future Scope 50
7. Conclusion 51
8. Reference/Bibliography 52
LIST OF FIGURES:

1. Figure 3.3.1: CONTEXT DIAGRAM

2. Figure 3.3.2: 1st Level DFD
3. Figure 3.4.1: E – R DIAGRAM
LIST OF TABLES

Table 1: Sub Division Table

Table 2: Sub Station Table

Table 3: Feeder Table

Table 4: Meter Details Table

Table 5: Feeder Status Detail Table

CHAPTER 1
1.1 OVERVIEW OF THE SYSTEM

The project entitled “Standard of Performance” aims to maintain all the records of
total number of Feeders, Meters, Sub-Station details, Sub-Division details. Manual
system that is employed is extremely laborious and quite inadequate. It only makes
the process more difficult and harder.

The aim of the project is to develop a system that is meant to partially computerized
the work performed in the Assam Power Distribution Corporation Limited which is
meant to show the efficiency of the “Feeder(s)”, commonly known as Electricity
Lines. With the help of these reports one can easily come to know which feeder is not
working properly and needs maintenance.

The system has two types of accessing modes, administrator and Sub – Station users.
Adding total number of new consumers, bills prepared, bills dispatched, revenue
collected i.e. bills payment works are managed by the Sub – division employees.
When a Sub – division level employee logs into the system he can view and add
number of bills prepared, bills dispatched, total revenue collected according to date –
wise. Sub – divisional username, passwords and creation of new Sub – Divisions are
managed by the administrator.

1|Page
1.2 PROBLEM STATEMENT

The old manual system was suffering from a series of drawbacks. Since whole of the
system was to be maintained with hands the process of keeping, maintaining and
retrieving the information was very tedious and lengthy. The records were never used
to be in a systematic order. There used to be lots of difficulties in associating any
particular transaction with a particular context. If any information was to be found it
was required to go through the different registers, documents there would never exist
anything like report generation. There would always be unnecessary consumption of
time while entering records and retrieving records. One more problem was that it was
very difficult to find errors while entering the records. Once the records were entered
it was very difficult to update these records

2|Page
1.3 PROPOSED SYSTEM

The project “Standard of Performance” is a website to develop a system that is meant

to show the efficiency of the “Feeder(s)”, commonly known as Electricity Lines in
which one can easily come to know which feeder is not working properly and needs
maintenance.

This website is helpful to the admin(s) of the various Sub-Station(s) in Assam.

Admin(s) can log into the website and be benefited by the records of the feeders,
meters on a daily, weekly, monthly or yearly basis of a particular Sub-Station. This
leads to time saving since revenue reports can be generated instantly.

Information regarding Sub-Division(s), Sub-Station(s), Feeder(s) along with Meter(s)

reports is safely stored in the database which can be accessed from anyplace, anytime
with the use of login credentials.

3|Page
1.4OBJECTIVES

This project will serve the following objectives –

• Enhance and keep Meter details.

• Update and maintain Sub-Division specifics.
• Add and keep up Sub-Station details.
• Keep updating Feeder details.

4|Page
CHAPTER 2
REQUIREMENT SPECIFICATION

The final output is the requirements specification document (SRS). For smaller
problems or problems that can easily be comprehended; the specification activity
might come after the entire analysis is complete. However, it is more likely that
problem analysis and specifications are done concurrently. All the information for
specification activity follows the analysis activity. The transition from analysis to
specification should also not be expected to be straightforward, even if some formal
modeling is used during analysis.

Essentially, what passes from requirements analysis activity to the specification

activity is the knowledge acquired about the system. The modeling is essentially a
tool to help obtain a thorough and complete knowledge about the proposed system.

ANALYSIS OF FACTUAL DATA

Analysis of data is a process of inspecting, cleaning, transforming, and modeling data

with the goal of highlighting useful information, suggesting conclusions, and
supporting decision making. Data analysis has multiple facets and approaches,
encompassing diverse techniques under a variety of names, in different business,
science, and social science domains.

Data mining is a particular data analysis technique that focuses on modeling and
knowledge discovery for predictive rather than purely descriptive purposes.

IDENTIFICATION OF ESSENTIAL REQUIREMENT

Identification of essential requirements is an important task in developing the project.

In this system the essential requirements are identified through surveying. By
surveying, the important needs of the user in our website are known. In the surveying,
the different possibilities of tour information that have to be included in the website is
given by questionnaire.

5|Page
SELECTION OF REQUIREMENT STRATEGIES

From the survey analysis graph, it is clear that which are all the requirements that the
user requires the most. It is decided to include the required information and omit the
less priority ones.

DEFINITION OF INPUT REQUIREMENTS

SUB STATION LOGIN SYSTEM

Sub Station Operator of the organization will carry out his own login with username
and password provided by the admin to associate to their application. This will enable
the system to display Feeder and Meter status when the Operator logs in. Here a Sub-
Station level Sub Station Operator can add new information such as new Sub-Station
id, Sub-Station name, No of Transformer, Transformer capacity and it can be saved.
Requiring a login process will also add greater security to the system, as once a Sub -
Station has logged in with their username and password, they will be the only person
able to update their information and can also view the information.

ADMINISTRATION LOGIN SYSTEM

The login process will be as straightforward as possible, using an intuitive form

layout, with the necessary username and password. The admin will monitor the
information and he can change the username and password of other employees. He
can also create new substation under any circle.

DEFINITION OF PROCESSING REQUIREMENTS

The user interface for this system will have to be simple and clear. Most importantly,
the pages must be easy to read, easy to understand and accessible. The colour scheme
should be appropriate to provide familiarity with the university and there should be no
contrast issues.

6|Page
These are many functions the system can perform and these must be logically grouped
or displayed in an intuitive order to allow the user to perform tasks quickly without
getting lost in excessive amounts of text. The system must also display a large amount
of information and to avoid confusion this must be displayed in categories or in
different pages. Furthermore, a small amount of information may be displayed
initially, for example with a certain limit on date or amount, and the ability to view
more in-depth information on the subject should be apparent.

The different information displays and functionality objects should be individually

distinguishable, allowing the user to navigate through recognition, rather than recall in
addition, each function must provide the ability to cancel, leaving the user with the
ability to rectify mistakes, and every page should include the ability to return to a
central location of the system, ensuring that the user does not get lost within the
system with no convenient way to navigate.

The system will provide different views for different users, allowing multiple access
levels. For example, an employee can only login with the username and password
provided by admin, whereas an administrator can change the username and password
of employees and will have many more privileges. Being an online system, it will
naturally be viewable from any computer with an internet connection, allowing
admissions from home, for example. This will provide far more accessibility than if it
were written in a language with only limited online capability as any computer is a
potential work station, rather than relying on the program being installed.

DEFINITION OF OUTPUT REQUIREMENTS

The most important function is to show the list of working feeders and meters under
the circumstances made by the sub stations.

7|Page
OBJECTIVE OF SRS

The objective of this SRS document is to specify software requirements of the

electricity feeders. It is intended to be a complete specification of what functionality
the electricity feeder provides. The main purpose of the system is to view tasks
carried out by different peoples in the organization according to date wise. Specific
design and implementation details will be specified in a future document.

OVERVIEW OF SRS

SRS will include two sections.

Overall Description will describe major components of the system, interconnection

and external interfaces.

Specific Requirements will describe the functions of actors, their role in the system
and constraints.

OVERALL DESCRIPTION

The SRS document will give further details on the overall product description,
including the hardware, software, and communications interfaces, product functions,
user characteristics, and any assumptions that will be made.

SPECIFIC REQUIREMENTS

The SRS document will also include the specific requirements needed. These will
include the functions, performance, design, and software attributes. This document is
organized in a logical manner and is easy to follow. Readers should refer to the table
of contents, appendices, or index if looking for something in specific. Otherwise,
reading this document from start to finish will start with a vague description and get
more specific and detailed as changing sections and reading further.

8|Page
2.1 TOOLS AND TECHNOLOGY USED

Software Specification –

• Front – end : HTML, JavaScript, CSS

• Back – end : MySQL Server
• IDE : NetBeans 11.3
• Web server : Apache
• Server – side scripting : PHP 7.4.10
• Operating System : Windows 10 Pro
• System Type : 64-bit Operating System, x64-based processor

Hardware Specification –

• Processor : Intel® Core™ i5-8250 CPU

• Installed Memory (RAM) : 4.00GB
• Hard Drive (ROM) : 1TB

9|Page
2.2 FEASIBILITY STUDY

Feasibility study is the phase in which the analyst checks that the candidate system is
feasible for the organization or not. This entails identification, description &
evaluation of the system. Feasibility study is done to select the best system that meets
the performance requirement.

If the feasibility study is to serve as a decision document, it must answer key

questions.

1. Is there a new and better way to do the job that will benefit the user?

2. What are the costs and savings of the alternatives?

3. What is recommended?

The most successful system projects are not necessarily the biggest or most visible in
the business but rather those truly meet user's expectations.

FEASIBILITY CONSIDERATION

Three key considerations are involved in the feasibility study. They are as follows: -

Economic Feasibility

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

We analyze the candidate system (computerized system) as more feasible than the
manual system because it saves money, time and manpower. It is also feasible
according to cost benefits analysis.

Technical Feasibility

Technical feasibility centers around the technology used. It means the candidate
system is technically feasible i.e. it doesn't have any technical faults and work

10 | P a g e
properly in the given environment. Our system is technically feasible; it is providing
us required output.

Behavioural Feasibility

Behavioural feasibility is the analysis of behaviour of the candidate system. In this we

analyse whether the candidate system is working properly or not. If working than it
communicating properly with the environment or not. All this matter is analysed and a
good candidate system is prepared. Due to the change of system and the change in
behaviour of the users, these factors are also analysed.

11 | P a g e
CHAPTER 3
SYSTEM DESIGN

System design is the phase that bridges the gap between problem domain and the
existing system in a manageable way. This phase focuses on the solution domain, i.e.
“how to implement”?
It is the phase where the SRS document is converted into a format that can be
implemented and decides how the system will operate.
In this phase, the complex activity of system development is divided into several
smaller sub-activities, which coordinate with each other to achieve the main objective
of system development.

Elements of a System:
 Architecture – This is the conceptual model that defines the structure,
behaviour and more views of a system. We can use flowcharts to represent to
illustrate the architecture.
 Modules – This are components that handle one specific task in a system. A
combination of the modules makes up the system.
 Components – This provides a particular function or group of related
functions. They are made up of modules.
 Interfaces – This is the shared boundary across which the components of the
system exchange information and relate.
 Data – This is the management of the information and data flow.

12 | P a g e
 3.1 STRUCTURE CHART

BILLING AND REVENUE MANAGEMENT SYSTEM

PROCESS 1.0 PROCESS 2.0 PROCESS 3.0 PROCESS 4.0 PROCESS 5.0

MASTER SUB STATION FEEDER DETAILS ENTRY STATUS REPORT

ENTRY ENTRY ENTRY GENERATION

13 | P a g e
 3.2 MODULE DESCRIPTION

In the proposed system we have divided the information into two modules:

ADMINISTRATOR:
The Administrator has the right to add new Sub Station, Sub Division, Feeder, Meter
Details and control the whole website.

EMPLOYEE:
The employees are the ones who will look after the Feeders and Meters which are in
the working stage and which are not in the working stage and also look after the
smooth functioning of the website.

14 | P a g e
 3.3 DATA FLOW DIAGRAM

A data flow diagram (DFD) is a graphical representation of the “flow” of data

through an information system, modeling its process aspects. A DFD is often used as
a preliminary step to create an overview of the system without going into great detail,
which can later be elaborated
A DFD shows what kind of information will be input to and output from the system,
how the data will advance through the system, and where the data will be stored. It
does not show information about process timing or whether processes will operate in
sequence or in parallel, unlike a traditional structured flowchart which focuses on
control flow, or a UML activity workflow diagram, which presents both control and
data, flows as a unified model. A data flow diagram (DFD) maps out the flow of
information for any process or system. It uses defined symbols like rectangles, circles
and arrows, plus short text labels, to show data inputs, outputs, storage points and the
routes between each destination. Data flowcharts can range from simple, even hand-
drawn process overviews, to in-depth, multi-level DFDs that dig progressively deeper
into how the data is handled. They can be used to analyze an existing system or model
a new one. Like all the best diagrams and charts, a DFD can often visually say things
that would be hard to explain in words, and they work for both technical and
nontechnical audiences, from developer to CEO. That’s why DFDs remain so popular
after all these years. While they work well for data flow software and systems, they
are less applicable nowadays to visualizing interactive, real-time or database-oriented
software or systems. Using any convention’s DFD rules or guidelines, the symbols
depict the four components of data flow diagrams.

1. External Entity: An outside system that sends or receives data, communicating

with the system being diagrammed. They are the sources and destinations of
information entering or leaving the system. They might be an outside organization or
person, a computer system or a business system. They are also known as terminators,
sources and sinks or actors. They are typically drawn on the edges of the diagram.

15 | P a g e
2. Process: Any process that changes the data, producing an output. It might perform
computations, or sort data based on logic, or direct the data flow based on business
rules. A short label is used to describe the process, such as “Search Feeder.”

3. Data store: Files or repositories that hold information for later use, such as a
database table or a membership form. Each data store receives a simple label, such as
“Save”

4. Data flow: The route that data takes between the external entities, processes and
data stores. It portrays the interface between the other components and is shown with
arrows, typically labeled with a short data name, like “Feeder Status”.

The various symbols used in data flow diagram are -

A circle or a bubble represents a process that transforms

incoming data flow(s) into outgoing data flow(s).

A square defined a source or destination of system data.

An arrow identifies data flow – data in motion. It is a pipeline

through information flows.

An open rectangle is a data-store or a temporary repository of

data.

16 | P a g e
 Context Diagram (0 Level DFD)

Get feeder details provide sub division/ station details

Provide meter details

Standard of
Engineer Admin
Performance

Add/update feeder Feeder details

Status details Get Report

Figure 3.3.1: Context Diagram

17 | P a g e
 1st Level DFD

1.0
Admin Provide details
Master Entry
store Sub_division_details
Process

collect
2.0
Make entry of sub station
Sub Station Entry
store Sub_Station_details
Process

store Meter_details

3.0
Provide feeder details collect
Feeder Details Entry
Get feeder details collect
Process

store Feeder_details

4.0
Update feeder status collect
Status Entry Process

store Feeder_status

Engineer

5.0 collect

Get Report Report Generation collect

Query for report Process collect

Figure 3.3.2: 1st Level DFD

18 | P a g e
 3.4 ENTITY RELATIONSHIP DIAGRAM

An entity-relationship diagram shows the relationship of entity sets stored in a

database. An entity in this context is an object, a compound of data. An entity set is a
collection of similar entities. These entities can have attributes that define its
properties.
The following symbols are used in an ER diagram –

19 | P a g e
 Timing
Meter_no Feeder_name
Sub_Station_id

Feeder_no
Meter_type

Feeder month
Output_voltage
Meter M
Feeder_type
M
Input_voltage
Date

Managed Status
By
Connected
To
Sub_Station_id

Total_capacity Name_Of_Sub_Station

1 1
Sub Station M

Sub_Division_id
Under
Sub_Station_id

Transformer_Capacity

No_Of_Transformer Sub_Division_name

Sub_Division_id
1

Sub Division Officer_in_charge

Sub_Division_address

Contact_No District

Figure 3.4.1: Entity-Relationship Diagram

20 | P a g e
 3.5 DATA DICTIONARY

Sl. Source Constraint

Field Name Description
No. Table
1 Contact_No Contact Sub
Number of the Division
Sub Division Table
Officer
2 Date Date of Feeder
Electricity Status
Report Table
3 District District of the Sub
Sub Division Division
Table
4 Efficiency Efficiency of Feeder
the feeder Status
Table
5 Feeder_Name Name of the Feeder
feeder Table
6 Feeder_No Unique Feeder Foreign
identification Status Key
number of the Table
feeder
7 Feeder_No Unique Feeder Primary
identification Table Key
number of the
feeder
8 Feeder_Tye Type of the Feeder
Feeder table
9 Hours Time of Feeder Feeder
not working Status
table
10 Input_Voltage Supply of Meter
Voltag in the Table
Meter
11 Meter_No Unique Meter Meter Primary
Number Table Key
12 Meter_Type Type of Meter Meter
Table

21 | P a g e
 13 No_of_Transformer Number of Sub Station
Transformers Table
in a Sub-
Station
14 Not_Working_From Starting Time Feeder
of Feeder not Status
working Table
15 Not_Working_To Ending Time Feeder
of Feeder not Status
working Table
16 Officer_in_Charge Name of the Sub
Officer in Division
charge of a Table
Sub Division
17 Output_Voltage Voltage Meter Table
releases by the
Meter
18 Sub_Division_Address Address of the Sub
Sub Division Division
Table
19 Sub_Division_id Unique Sub- Sub Primary
Division Division Key
identification Table
number
20 Sub_Division_id Unique Sub- Sub Station Foreign
Division Table Key
identification
number
21 Sub_Division_Name Name of the Sub
Sub Division Division
Table
22 Sub_Station_id Unique Sub- Sub Station Primary
Station Table Key
identification
number
23 Sub_Station_id Unique Sub- Feeder Foreign
Station Status Table Key
identification
number
24 Sub_Station_id Unique Sub- Meter Table Foreign
Station Key
identification
number

22 | P a g e
 25 Sub_Station_id Unique Sub- Feeder Table Foreign Key
Station
identification
number
26 Sub_Station_Name Sub Station Name of the
Table Sub Station
27 Total_Capacity Sub Station Capacity of a
Table particular
Transformer
28 Transformer_Capacity Sub Station Capacity of a
Table particular
Transformer

23 | P a g e
 3.6 TABLE STRUCTURE

Table 1: Sub Division Table

Field Name Datatype Size Constraints

sd_id varchar 40 Primary Key
sd_name varchar 50
sd_address varchar 100

officer varchar 50

cno bigint 20

district varchar 50

Table 2: Sub Station Table

Field Name Datatype Size Constraints

ss_id varchar 40 Primary Key
sd_id varchar 50 Foreign Key
ss_name varchar 50
no_transformer int 11
t_capacity varchar 50
total_capacity varchar 50

24 | P a g e
Table 3: Feeder Details Table

Field Name Datatype Size Constraints

feeder_no varchar 30 Primary Key
f_Name varchar 50
feeder_Type varchar 50
ss_id varchar 30 Foreign Key

Table 4: Meter Details Table

Field Name Datatype Size Constraints

meter_no varchar 40 Primary Key
ss_id varchar 50 Foreign Key
meter_type varchar 50
i_voltage varchar 50
o_voltage varchar 50

Table 5: Feeder Status Table

Field Name Datatype Size Constraints

feeder_no varchar 40 Foreign Key
ss_id varchar 50 Foreign Key
not_working_from varchar 50
not_working_to varchar 50
date varchar 50
hours decimal (40,0)
efficiency decimal (10,2)

25 | P a g e
CHAPTER 4
TESTING AND IMPLEMENTATION

SOFTWARE TESTING:

TESTING AND TYPES:

Testing makes a logical assumption that identify (a) whether all the parts of the
system are correct and (b) the goal of the candidate system is successfully achieved or
not. The first test is to see whether it provides correct output result or not as per user
requirements. Testing can be set to the process of “finding the errors we don’t know is
there”. The process of software testing aims not only at finding faults in the existing
software but also at finding measures to improve the software in terms of efficiency,
accuracy and usability. It mainly aims at measuring specification, functionality and
performance of a software program or application. Software testing can also provide
an objective, independent view of the software to allow the business to appreciate and
understand the risks of software implementation. Test techniques include the process
of executing a program or application with the intent of finding errors or other
defects, and verifying that the software product is fit for use.

Software should be thoroughly tested before implementing it, as regards its individual
program, the system as a whole, user’s acceptance etc. Effective testing early in the
process translates directly into a long term.

Testing involves:
(A) Module Testing
(B) Sub – System Testing
(C) System Testing
(D) Acceptance Testing

26 | P a g e
With the help of the following diagram we can illustrate the testing process:

UNIT TESTING

SUB – SYSTEM TESTING

SYSTEM TESTING

ACCEPTANCE TESTING

27 | P a g e
MODULE TESTING OR UNIT TESTING

Module testing is defined as a software testing type, which checks individual

subprograms, subroutines, classes, or procedures in a program. Instead of testing
whole software program at once, module testing recommends testing the smaller
building blocks of the program. Module testing is a white box oriented. The objective
of doing Module testing is not to demonstrate proper functioning of the module but to
demonstrate the presence of an error in the module. It checks for errors in individual
modules isolating them from the rest of software product and the errors are corrected
for each individual unit. Unit test are a collection of tests written by a developer
during the software development process. Module tests are a collection of tests
written by a tester after some code has been written by a developer. This type of
testing may be conducted in parallel for several modules at a time. Here the program
unit or functions are tested with:

- Legal data values i.e. simple realistic values

- Null values
- Illegal data values and
- Program’s behavior is tested under stress of extreme conditions (either the
quality of data we provide or its opening environment).

Module Testing is recommended because

- Probability of identifying errors or bugs on smaller chunks of program
becomes higher.
- Multiple modules can be tested simultaneously and hence supports parallel
testing.
- Complexity of testing can be easily managed.

28 | P a g e
SUB - SYSTEM TESTING

Sub-System involves testing a collection of modules that have been integrated into
sub-system. The sub-system may be independently designed and implemented. This
phase involves testing collections of modules which have been integrated into sub-
systems. Sub-systems may be independently designed. The most common problems
which arise in large software systems are sub-system interface mismatches. The sub-
system test process should therefore concentrate on the detection of interface errors by
rigorously exercising the interfaces. Sub systems are integrated to make up the entire
system. The testing process is concerned with finding errors that result from
unanticipated interactions between sub-systems and system components. It is also
concerned with validating that the system meets its functional and non-functional
requirements. The errors that are not discovered into modules of unit testing are not
discovered into modules of unit testing but discovered into sub-system testing may be:
A. Errors in the interface between two sub-systems.
B. Errors or misunderstanding in interpreting the module specification.
C. Errors due to side-effects of a module.

29 | P a g e
SYSTEM TESTING

System testing is a method of monitoring and assessing the behavior of the complete
and fully-integrated software product or system, on the basis of pre-decided
specification and functional requirements. In System Testing interface between two
sub-systems are tested because errors existed in the interface between sub-systems
may not be visible until they are combined tested as a complete unit. System testing
means testing the system as a whole. All the modules/components are integrated in
order to verify if the system works as expected or not. System testing is done after
integration testing. This plays an important role in delivering a high-quality product.
In System testing, the functionalities of the system are tested from an end-to-end
perspective. System Testing is usually carried out by a team that is independent of the
development team in order to measure the quality of the system unbiased. It includes
both functional and Non-Functional testing.

Key Areas of System Testing:

Some of the aspects, on which system testing focuses are:
- Performance: It makes sure that the software system performs as per
requirements of the user, without depicting any defects or issues.
- Security: Protects the product from any security breaches, data theft, etc.,
which can sacrifice critical data & information of the organization.
- Recovery: Ensures that the recovery of the system is as per expectations and
in an accurate condition.
- Interface: System testing also focuses on the interface of the product and
ensures that all requirements are met accurately and no issues occur when two
components of the system are integrated together.

After combining the individual sub-system, the overall program is tested for
determining whether the correct individual sub-system fits together properly into a
correct whole, the system.
System Testing should be concerned with ‘checking’ so that the system meets the
organizations objectives and requirements.

30 | P a g e
System Testing is divided into two types:
 White-Box Testing or Structural Testing
 Black-Box or Functional Testing
WHITE - BOX TESTING or STRUCTURAL TESTING

White-Box Testing is concerned with the implementation of the programs. In this type
of testing different programming structures and data structures used in the programs
are tested for proper operations. This test concentrates on the examinations of coding
methods. The system software engineers and programmers formulate test-cases and
select test data. The system designers create test cases which have the possibility of
locating errors. White box testing involves looking at the structure of the code. When
you know the internal structure of a product, tests can be conducted to ensure that the
internal operations performed according to the specification. And all internal
components have been adequately exercised. White box testing technique is used by
both the developers as well as testers. It helps them to understand which line of code
is actually executed and which is not. This may indicate that there is either a missing
logic or a typo, which eventually can lead to some negative consequences.

White-Box Testing is done to ensure:

- That all independent paths within a module have been exercised at least once.
- All logical decisions verified on their true and false values.
- All loops executed at their boundaries and within their operational bounds
internal data structures validity.

White-Box Testing discovers the following types of bugs:

- Logical error tends to creep into our work when we design and implement
functions, conditions or controls that are out of the program.
- The design errors due to difference between logical flow of the program and
the actual implementation.
- Typographical errors and syntax checking.

31 | P a g e
BLACK - BOX or FUNCTIONAL TESTING

Black box testing, also known as Behavioral Testing is a software testing method in
which the internal structure/design/implementation of the system being tested is not
known to the tester. These tests can be functional or non-functional, though usually
functional. Black-Box testing is concerned with the proper examination of the
programs specifications. In this testing, each functions as well as sub-programs used
in the main programs are first identified.
Hereafter, test cases are devised to test each function or sub-program separately. Test
cases are decided solely on the basis of the requirement or specifications of the
programs are not on the basis of the coding of the modules or the type of the data
structures used.

This method attempts to find errors in the following categories:

- Incorrect or missing functions.
- Interface errors.
- Errors in data structures or external database access.
- Behavior or performance errors.
- Initialization and termination errors.

Following black box testing techniques are used for testing the software application.
- Boundary Value Analysis (BVA)

- Equivalence Class Partitioning

- Decision Table based testing

- Cause-Effect Graphing Technique

- Error Guessing

32 | P a g e
ACCEPTANCE TESTING

Acceptance Testing is the system testing performed by the customer to determine

whether or not to accept the delivery of the system. User Acceptance is defined as a
type of testing performed by the Client to certify the system with respect to the
requirements that was agreed upon. This testing happens in the final phase of testing
before moving the software application to the Market or Production environment. The
main purpose of this testing is to validate the end to end business flow. It does not
focus on cosmetic errors, Spelling mistakes or System testing. This testing is carried
out in a separate testing environment with production like data setup. It is a kind of
black box testing where two or more end users will be involved. Formal testing with
respect to user needs, requirements, and business processes conducted to determine
whether or not a system satisfies the acceptance criteria and to enable the user,
customers or other authorized entity to determine whether or not to accept the system.
This last phase of testing determines whether or not the program is considered as
finished product and can be released for general use. It differs from module testing or
system testing in the two following ways.
In acceptance testing we check the program’s user-friendliness, robustness and on-
line help assistance. Acceptance testing often demonstrates errors in the system
requirements definitions. It is the process of setting with real data in the information,
which the system in intended to manipulate.
A system‘s acceptance testing is final system test performed by end-users using real
data over an extended time period. It is an extensive test that addresses two levels of
acceptance testing.

 Verification by Alpha Testing

 Verification by Beta Testing

33 | P a g e
ALPHA TESTING

Alpha testing is a type of acceptance testing; performed to identify all possible

issues/bugs before releasing the product to everyday users or the public. The focus of
this testing is to simulate real users by using a black box and white box techniques.
The aim is to carry out the tasks that a typical user might perform. Alpha testing is
carried out in a lab environment and usually, the testers are internal employees of the
organization. As such alpha testing is done on a prototype, in-depth reliability testing,
installation testing, and documentation testing can be ignored. A good alpha test must
have a well-defined Test plan with comprehensive test cases. Various activities
involved in alpha testing are logging defects, fixing defects, retesting, several
iterations, etc. Although Alpha testing is not completely functional, QA team must
ensure that whatever is on hand should be thoroughly tested, especially those which
has to be sent to the customer. To put it as simple as possible, this kind of testing is
called alpha only because it is done early on, near the end of the development of the
software, and before beta testing. Alpha testing has two phases:
- The first phase of testing is done by in-house developers. They either use
hardware-assisted debuggers or debugger software. The aim to catch bugs
quickly. Usually while alpha testing; a tester will come across to plenty of
bugs, crashes, missing features, and docs.
- While the second phase of alpha testing is done by software QA staff, for
additional testing in an environment. It involves both black box and White
Box Testing.

34 | P a g e
BETA TESTING
Beta Testing is one of the Acceptance Testing types, which adds value to the product
as the end-user (intended real user) validates the product for functionality, usability,
reliability, and compatibility. Inputs provided by the end-users helps in enhancing the
quality of the product further and leads to its success. This also helps in decision
making to invest further in the future products or the same product for improvisation.
Since Beta Testing happens at the end user’s side, it cannot be the controlled activity.

Purpose of Beta Testing:

- Beta Test provides a complete overview of the true experience gained by the
end users while experiencing the product.
- It is performed by a wide range of users and the reason for which the product
is being used varies highly. Marketing managers focus on target market’s
opinion on each and every feature, while a usability engineer / common real
users focus on product usage and easiness, technical users focus on
installation and un-installation experience etc.
- Real world compatibility for a product can be ensured to a greater extent
through this testing, as a great combination of real platforms is used here for
testing on a wide range of devices, OS, Browsers, etc.
- As a wide range of platforms which the end users are actually using, might
not be available to the internal testing team during the QA, this testing also
helps to uncover the hidden bugs and gaps in the final product.
- Few specific platforms will cause the product to fail with showstopper bug
which was not covered during QA. And this helps in improvising/fixing the
product to be a compatible one with all possible platforms.
- Known Issues, which are accepted by the Product Management team, may
take a great turn when the end user faces the same issue and may not be
comfortable while using the product. In such cases, this testing helps to
analyse the impact of known issues on the entire product as the user
experience gets hampered and is not acceptable for any successful business.

35 | P a g e
CHAPTER 5
DOCUMENTATION AND USER MANUAL
1. Home Page

36 | P a g e
 2. Sub Division Details Page

37 | P a g e
 3. Sub Division Update Details Page

38 | P a g e
 4. Sub Station Details Page

39 | P a g e
 5. Sub Station Update Details Page

40 | P a g e
 6. Meter Details Page

41 | P a g e
 7. Meter Details Update Page

42 | P a g e
 8. Feeder Details Page

43 | P a g e
 9. Feeder Details Update Page

44 | P a g e
 10. Feeder Status Page

45 | P a g e
11. Feeder Status and Set Status Page

46 | P a g e
 12. Feeder Status Update Page

47 | P a g e
13. Report Generation Page

48 | P a g e
14. Feeder Status Report Generation PDF File

49 | P a g e
CHAPTER 6
FUTURE SCOPE
Following are some of the features that can be added in the software to enhance it in
the future:

- We can enhance the system by converting into app for android and iOS
platforms.
- Adding a login portal to make the website more secure.

50 | P a g e
CHAPTER 7
CONCLUSION
This system, being the first we have created in PHP, has proven more difficult than
originally imagined. While it may sound simple to add new information and process
the information, much more is involved in the arrangement and displaying of the data.
Every time progress was made and features were added, ideas for additional features
or methods to improve the usability of the system made them apparent. Furthermore,
adding one feature meant that another required feature was now possible and
balancing completing these required features with the ideas for improvement as well
as remembering everything that had to be done was a project in itself.

Debugging can sometimes be a relatively straight forward process, or rather finding

out what we must debug can be. Since so many parts of this system are integrated into
one another, if an error occurs on one page, it may be a display error, for example; it
may be the information is not correctly read from the database; or even that the
information is not correctly stored in the database initially, and all three must be
checked on each occasion. This slows down the process and can be frustrating if the
apparent cause of a problem is not obvious at first. Language used must be simple and
easy to understand and compatibility is paramount. If this system were not designed
as an entirely web based application, it would not have been possible to recreate its
current state of portability.

Overall, the system performs well, and while it does not include all of the features that
may have been desired, it lives up to initial expectations. The majority of features that
are included work flawlessly and the errors that do exist are minor or graphical.

51 | P a g e
CHAPTER 8
BIBLIOGRAPHY
1. 1. Welling, L. & Thomson, L. (2016). PHP and MySQL Web Development, 5th Edition.
Addison-Wesley Professional.
2. Duckett, J. (2011). HTML and CSS: Design and Build Websites, 1st Edition. John Wiley
& Sons.
3. Ramakrishnan, R. & Gehrke, J. (2002). Database Management Systems, 3rd Edition.
McGraw-Hill.
4. https://www.w3schools.com/sql/
5. https://www.tutorialspoint.com/sql/index.htm
6. https://www.w3schools.com/php/default.asp
7. https://www.w3schools.com/css/default.asp
8. https://www.w3schools.com/bootstrap/bootstrap_ver.asp
9. https://www.w3schools.com/html/html_styles.asp
10. https://www.tutorialspoint.com/html/index.htm
11. https://www.youtube.com/

52 | P a g e