1.

Scope of Work

The scope of project objective is to study, analyse, design, develop, training and
provide support for a web based Management Information System for Distribution
wing, Personnel wing, Miscellaneous wing and some part of Transmission wing.

a.) DISTRIBUTION WING

S.NO Functions
1 Details of billing facility and relates information for consumers at 33KV sub stations
2 Details in respect of issue of new transformers, tripping, replacement of damaged transformers
transformers
3 Details of Tripping of 33KV lines
4 Plinth-wise details of damaged transformers
5 Details of newly energized sub-stations and transmission lines
6 Details of feeder wise line chart and distribution transformer-wise details of customers.
7 History of Power and Distribution Transformers , Switchgears and Electronic Meters.
8 Details of Star Materials and Reserve Level
9 Detail in respect of tripping and breakdown of 33KV and lower capacity transmission lines
10 Details of Capacitor box
11 Details of regularization of irregular Connections.
12 Maintaining consumer details and billing of consumers at 33KV sub-stations
13 Detail of samples energy meters for un-metered consumers
14 Energy balancing details, and maintaining Feeder-wise ledgers, transmission loss details of
33KV sub-stations
15 Detail of Revenue collection
16 Details of energy consumption and payment of large customers
17 Details for recovery status under Section 3 and Section 5
18 Details of electricity theft and other irregularities
19 Details of court cases
20 Details of work progress of advocates of Corporation
21 Details of electricity taxes from administration
22 Details of rural electrification work
23 Technical diary
24 Commercial diary
25 Collection of data for MIS at Head Quarter
26 Database creation for maintaining information of all the units in a district
27 Details of workers deployment
b.) MISCELLANEOUS

S.NO Functions
1 Details of related establishments to a wing
2 Inventory control and store management
3 Inventory details of deployed transformers
4 Details of pending bills of purchased materials and payments priorities
5 Details of new and R&R transformers
6 Availability and the allotment of PCC and other types of poles at stores
7 Weekly balance at various sub-stations
8 Repair details of transformers
9 Details of purchase of materials vis a vis targets
10 Details of supply of materials, available balance etc as per the purchase orders
11 Details of unused materials and their disbursement
12 Details of advance payments
13 Planning details

c.) PERSONAL WING

S.NO Functions
1 Codification of employees
2 Details of electrical accidents and liabilities there of
3 Details of union's demand and settlement
4 Details of union's incumbent
5 Details of hospitals for recognition
6 Recruitment of dependant of dead
7 Details of handicapped workers because of electrical accidents

d.) TRANSMISSION WING

Details required .

Since the list is only indicative and may be added/deleted/replaced during the System
Analysis period, it is required that the above list be limited to a deviation of +/-10 %at
the maximum.
2. Suggested Architecture:

The Multi-tier web based solution will be used for the development of Web based
MIS application. The architecture comprises of a web server, application server, and
database server. The general outlay of the system will be shown in the diagram:

NAS 4.0
Web server
User – 1 Presentation Layer
F
User – 2 HTTP Internet I
R Application Layer
User – 3 Intranet E (EJB)
W
User – 4 A Database Layer
L JDBC
L

Oracle
Database

Presentation Layer
This layer comprises of user interface for Web based MIS. This will provide dynamic
and interactive content to the client through browser. The interface will be designed to
work on both Netscape Navigator and Internet explorer.

Application Layer
This layer comprises of the programs on the application server that contain the
business logic of web based MIS. This application layer also contains the process that
handle data transfer across others layers.

Database Layer
This comprises of objects residing on the application server to connect web-based
database.

3. Software Environment

Server : Windows NT
Oracle Work Group at the Central Server and at the Zonal Servers
IPlanet Application Server, version 6.0 at the Central Server .
IPlanet Web Server 4.0 at the Central Server .
IPlanet Application Builder 4.0 at the Central Server .

4. Methodology & work plan for performing the assignment

The project will be broadly organised into several task. They are,
1. Requirement Study
2. Analysis and Design
3. Construction and Testing
4. On site Implementation and Testing
5. User Acceptance Testing
6. User Training & Parallel Run
7. Live Run
8. Maintenance & Warranty Support
9. Change Control Procedure

1. Requirement study
 Interact with end user to study the existing system and understand
the requirements. Process mapping and Finalise user requirements.

 System Requirement specifications (SRS)

The System Requirement Specification shall contain:

o A detailed description of all requirements

o Finalising functions, entity, relationships, Logical flow
diagram & control flow
o Detailed description of each process that will be performed
on the data to get successful results.
o Functional Description of each function i.e. Menu Options,
screen formats, Input forms, Display / Output screens,
reports layouts

 With prior concurrence from the clients and, Any deviations

beyond the stated requirement would be subject to change
Management Procedure.

2. Analysis and Design

 Development of DFD
 Development of Entity Relationship diagram
 Designing Prototype and Functional Specification
 Database designing

3. Construction and Testing

 Coding
Program Coding will be carried out as per System Design
documents and will be following structure coding with
appropriate comments at every stages.

 Unit testing

Internal testing team to make sure the functionality of the

programme as defined in SRS will carry out in unit testing.
 And it will be tested under the guidelines framed by Quality
Assurance and Testing Team.

 Debugging

Debugging will be done to rectify errors & ensure that defined

inputs will produce expected results.

 Integration Testing

Internal testing team to make sure the functionality of all the

integrated modules as defined in SRS will be carried out in
integration testing.

4. On site Implementation Testing

 Test Data creation
 Onsite Integration Testing with sample data to ensure correct
functioning of the integrated software. It will test individual
module and well as integrating of all modules, which combined in
the whole application with suitable test data.
 Onsite System Testing to ensure the correct functionality of the
complete Application Software. The test will aim to demonstrate
functionality of the Application Software as per approved SRS

5. User Acceptance Testing

 Acceptance test plan will contain the details of tests to be
performed with live data to demonstrate the correct functioning of
the Application Software as per approved SRS.
 An acceptance Test certificate shall be jointly signed, on successful
demonstration of functionality of the application.

6. User Training
 User Manual
 User Training
 Parallel run of the application

7. Live Run
 Live Run of the application.

8. Maintenance & Warranty Support

 User may encounter errors while operating the application. Hence,
the software will be adaptable to accommodate changes whenever
required by the user.
 Maintenance and Warranty support will commence from the date
of acceptance of the software.

9. Change Control Procedure

  The approved Document (SRS) will be considered a “Controlled
Document” and will form the guidelines for designing as well as
acceptance of the software. All changes of Approved document
shall be carried out through a change control Procedure which will
comprises of:
i. Logging of change request
ii. Approval of change request by Project Managers on both sides
iii. Agreement on impact of changes on time & effort/financial
implications
iv. Implementations of change

4. Deliverables

The following are the deliverables of project

 One copy of the “Software Requirement specification” document.
 System Design Document, which shall submitted after the acceptance of
the software.
 Tested application software (source and executables)
 User Manual
 Installation Manual

5. Software Quality Assurance

A team of expertise professionals works out for Software Quality Assurance (SQA) at
JMCO. The SQA Plan provides systematic approach to ensure the quality of the
software product. SQA assesses to evaluate the quality and capability of the program
used throughout the development cycle to ensure that each program meets its
requirements. The following Quality Assurance Practices with standard formats
performed during development & testing are applied to our software products to
ensure the quality of the product :

 Project Review
 Technical Review
 Construction Monitoring
 Business Rules
 Coding Standard
 Variable, File, Directory, Naming Convention
 Programme List
 Defect Log form
 Defect Tracking Report
 Change Request Form
 Daily Backup
 Security and Password to prevent unauthorized access

The Appendix A provides the additional information and the standard formats that
our team use for the inspection process. The given Appendix may be tailored
depending on the approved SRS.
 6. Project Management Structure and Role

Team Structure

Team Structure will constitute a team of consultants consisting of a Project Manager,

a Project leader, Module Leaders, Quality assurance personnel and Team members.

Project Manager 1

Project Leader 2

QA Team 3,4

Module Leader -1 Module Leader -2 Module Leader -3 Module Leader -4

Distribution wing Miscellaneous wing Personnel Wing Transmission (part)
5 6 7 8

Team Member - 9 Team Member - 13 Team Member - 15 Team Member - 17

Team Member - 10 Team Member - 14 Team Member - 16

Team Member - 11

Team Member - 12
The responsibilities of the Project Manager are mentioned as follows:

 Overall Responsibility for the project

 Overall co-ordination with TCS
 Responsible for ensuring & meeting project schedules
 Monitoring/Reviewing progress of the project
 Ensuring that project standards are adhered to
 Monitoring quality of the application

The responsibilities of the Project Leader are mentioned as follows:

 System analysis
 System Design
 Co-ordination of development status with module leader.
 Liaison with TCS
 System Design & acceptance
 Monitoring/Reviewing progress of Modules
 Incorporating all modules for interface.

The responsibilities of the Module Leader are mentioned as follows:

 System Design
 Assigning task to team members
 Program Development
 Ensuring quality of unit test
 System testing
 Monitoring preparation of documents

The responsibilities of the Quality Assurance are mentioned as follows:

 System Correctness
 Reliability
 System Efficiency
 Integrity
 Usability
 Testability

The responsibilities of the Team Members are mentioned as follows:

 Program Coding
 Unit test plan & test data preparation
 Unit testing of programs and result validation
 Providing assistance in system testing
 Documentation

7. Project Reporting
 The analysis, design and development will require proper and timely exchange of
information to avoid misinterpretation on various issues. To overcome this progress
reports will be sent on a regular basis to the Project Coordinator of TCS. The report
will highlight the progress of the project, problems encountered & outstanding issues,
if any.

TCS will ensure that any queries raised by us are responded back as early as possible
to avoid delay in project completion.

Our Team would tentatively complete the computerisation work in the above
functional areas in 4-months time frame, extended implementation support for two
(2) Weeks and will concurrently provide warranty support one (1) Year .

8. Work Plan and Time Line

This is Liable to be revised at the time of the project initiation and requirement
analysis phase with mutual agreement.

System Analysis

System Design

Construction and Testing

User Acceptance Testing

Training

Warranty

Phase 0 1 2 3 4 5 7
6 Months 8 9 10 11 12 13 14 15 16 17 18
9. Activities for software development

Activity Responsibility
Primary Supporting
Project Start up
Identify Project Coordinator TCS
Identify project Team JMCO
System Analysis JMCO
Prepare project Plan JMCO
Study Existing system, Analyse problems and requirement JMCO
Present System solution to TCS JMCO TCS
Prepare and document SRS JMCO
Review SRS JMCO
Approve SRS TCS JMCO
System Design JMCO
Prepare detail plan for design JMCO TCS
Identify system components JMCO
Identify tables and design database JMCO
Identify system input, outputs, queries and menu navigation JMCO
Prepare and review system design Document JMCO
Finalise coding Standards JMCO
System Construction and testing
Prepare detail plan for construction JMCO
Set up system construction environment JMCO
Preparation of unit test specifications JMCO
Prepare coding and unit testing JMCO
Prepare system test specifications JMCO
Prepare draft user & installation manual JMCO
Test the system as per system test specifications JMCO
Prepare acceptance test plan TCS
Verify the acceptance test plan JMCO
Acceptance Testing
Prepare detail plan of UAT TCS JMCO
Set up environment for acceptance testing TCS JMCO
Conduct acceptance test, report feedback &defects TCS JMCO
Correct defects JMCO
Update user manual &I Installation manual JMCO
Give formal acceptance of the system training TCS
Provide infrastructure for training TCS
Provide training to users & management JMCO TCS
Implementation & warranty support JMCO TCS
Prepare Implementation Plan TCS JMCO
Implement the System JMCO TCS
Implementation support for two (2) weeks JMCO TCS
Installation of application software JMCO TCS
Provide warranty support for one year JMCO TCS
Project wind-up TCS JMCO

APPENDIX A
INSPECTION PROCESS REFERENCES
This appendix provides the additional information and a brief idea about the
inspection process that our team implements by using various inspection forms. Treat
this information of the Appendix A as an Example; it will be tailored depending on
the Approved SRS.

A ) Inspection Checklists

The following checklists are provided to aid in inspections. The checklists given
below is useful for the inspection during walk-throughs. The checklists is not
intended to be all-inclusive, but only some of the points for inspections.

A .1) Analysis Report Inspection Checklist

Inspection Issues:

 Is the Analysis Report in the required format?

 Is the Analysis Report compliant with the Analysis Report Standards or a
written variance provided?
 Does the requirement specification portion of the Analysis Report capture all
of the requirements identified by the set of deficiencies?
 Does the design solution meet the specified requirements?
 Is the time and resource estimation realistic?
 Have all source and documentation files that need to be changed been
identified?

A.2) Implementation Inspection Checklist

Inspection Issues:

 Do all documents and code confirm to the applicable standards and guidelines
or other variance provided?
 Are all products, including documentation, necessary to implement are
complete and correct?
 Have the Unit Testing was performed in accordance with standards?
 Have all items passed the walk-through process?
 Does the proposed changes mentioned, what it is expected to do is meaningful
or not?
 Does the proposed changes mentioned will produce desirable effect or not.
That is, is it Effective and consolidated?

Variables
  Are the variables properly defined and given meaningful, clear, and consistent
names?
 Did all assigned variables have proper type consistency and casting?
 Are there any redundant or unused variables?
 Are all array references in bounds?

Loops and Branches

 Are all loops, branches, and logic constructions complete, correct, and
properly nested?
 Are all cases covered in an IF-THEN-ELSE or CASE block, including ELSE
or DEFAULT clauses?
 Does the normal case flow follow the IF, not the ELSE?
 Does each cases in a CASE statement have a break?
 Does every switch statement have a default?
 Are loop termination conditions obvious and invariably achievable?
 Are indexes or subscripts properly initialized just prior to the loop?
 Does the code in the loop avoid manipulating the index variable or using it
upon termination of the loop?

Defensive Programming

 Are indexes, pointers, and subscripts tested against array, record, or file
bounds?
 Are input arguments tested for validity and completeness?
 Are divisors tested for zero and noise?
 Are all output variables assigned?
 Are the correct data being operated on in each statement?
 Is every memory allocation being deallocated?
 Are files checked for existence before attempting to access them?
 Are cleanup routines used to make sure all files and devices are left in the
correct state upon program termination?

Documentation

 New Name: All the New data name, file name, and/or labels documented?
 New Error Message: Are all the error messages included in their proper place
in the documentation?
 Deleted Error Message: Are all the deleted error messages included in their
proper place in the documentation?
 Is the code clearly and adequately documented?
 Are there any inconsistencies between code and comments?