novec expansion identification system · novec expansion identification system concept of...

NOVEC EXpansion Identification System

Concept of Operations

March 1, 2015

Revision B

NOVEC EXpansion

Identification System

Concept of Operations

SYST 699 - Spring 2015

Austin Orchard

Brian Smith

Tygue Ferrier

Austin Orchard

Brian Smith

Tygue Ferrier

Version Revision Status Date

A Initial Release Feb 3, 2015

B Revision 2, Section 2, 5, 6 Mar 1, 2015

C Revision 3, Section 6 Mar 3. 2015

D Final – Customer Signoff Mar 10, 2015


Concept of Operations Version: D

4

Table of Contents [1]

1.0 Scope ....................................................................................................................................... 6 1.1 Identification ................................................................................................................................. 6 1.2 Document Overview .................................................................................................................... 6

1.2.1 Relationship to System Development .........................................................................................................6 1.3 System Overview .......................................................................................................................... 6

1.3.1 NEXIS ............................................................................................................................................................................6 1.3.2 Local Data Reporting ............................................................................................................................................7 1.3.3 Concept Diagram for Proposed Enhancement ........................................................................................8

2.0 Referenced Documents ...................................................................................................... 9

3.0 Existing System .................................................................................................................. 10 3.1 Background, Objectives, and Scope ....................................................................................... 10 3.2 Operational Policies and Constraints ................................................................................... 10

3.2.1 NOVEC Charter ..................................................................................................................................................... 10 3.2.2 LCAL ........................................................................................................................................................................... 10 3.2.3 LOLA .......................................................................................................................................................................... 10

3.3 Description of the Current System ........................................................................................ 11

4.0 Justification For and Nature of Changes...................................................................... 12 4.1 Justification of changes ............................................................................................................. 12 4.2 Description of Desired Changes ............................................................................................. 12

5.0 Concepts for the proposed system ............................................................................... 13 5.1 Background, objectives, and scope........................................................................................ 13 5.2 Operational Policies and Constraints ................................................................................... 13 5.3 Description of the Proposed System ..................................................................................... 13

5.3.1 System Components .......................................................................................................................................... 14 5.4 Modes of Operation.................................................................................................................... 14 5.5 User Classes ................................................................................................................................. 14

5.5.1 Organizational Structure ................................................................................................................................. 15 5.5.2 Profiles of User Classes .................................................................................................................................... 15

6.0 Operational Scenarios ...................................................................................................... 16 6.1 User Goal Use Case Diagram .................................................................................................... 16 6.2 User Goal Use Case Descriptions ............................................................................................ 16

6.2.1 Scenario 1: Collect Development Data ..................................................................................................... 16 6.2.2 Scenario 2: Generate Reports ....................................................................................................................... 18 6.2.3 Scenario 3: Amend Data Entry ..................................................................................................................... 19

7.0 Summary of Impacts ......................................................................................................... 20 7.1 Operational Impacts .................................................................................................................. 20

7.1.1 User Interface for Query .................................................................................................................................. 20 7.1.2 User Account Registration .............................................................................................................................. 20 7.1.3 Log File Reporting .............................................................................................................................................. 20 7.1.4 System Backup ..................................................................................................................................................... 20

7.2 Organizational Impacts ............................................................................................................ 20 7.2.1 NOVEC Headquarters ........................................................................................................................................ 20



5

7.2.2 NOVEC Project Planning .................................................................................................................................. 20 7.2.3 NOVEC IT ................................................................................................................................................................. 20 7.2.4 NOVEC Regional Offices ................................................................................................................................... 20

7.3 Impacts During Development ................................................................................................. 21 7.3.1 Firewall..................................................................................................................................................................... 21 7.3.2 Permissions ............................................................................................................................................................ 21

8.0 Analysis of the Proposed System .................................................................................. 22 8.1 Summary of Improvements ..................................................................................................... 22

8.1.1 Increased Efficiency of the Project Planning Agency ....................................................................... 22 8.1.2 Increased Accuracy ............................................................................................................................................ 22

8.2 Disadvantages and Limitations .............................................................................................. 22 8.2.1 Increased Cost to the Project Planning department ......................................................................... 22

8.3 Alternatives Considered and Trade Offs .............................................................................. 22 8.3.1 Lease of Data.......................................................................................................................................................... 22 8.3.2 Manual Processing of Data ............................................................................................................................. 22

9.0 Appendices .......................................................................................................................... 23 9.1 Acronyms and Abbreviations.................................................................................................. 23



6

1.0 Scope

1.1 Identification

This NOVEC EXpansion Identification System (NEXIS) concept of operations document, refers

to the software, hardware, and design documentation associated with this design and

development effort desired by the not for profit NOVEC Project Planning group [1].

1.2 Document Overview

The NOVEC EXpansion Identification System (NEXIS) Concept of Operations (ConOps)

characterizes proposed NEXIS system. This document is written from the viewpoint of the end

user. The goal of this document is to describe the existing system, functional gap, and proposed

concept of operation of the NEXIS system. The description of the system takes into account the

major stakeholders for the system and key capabilities needed by the stakeholders.

This document is intended to provide the initial definition of the desired system enhancements.

It is written using terminology and notation that can be verified by the users, while at the same

time, is intended to be sufficiently complete and non-ambiguous to allow the scope and cost of

the enhancement effort to be estimated. [2]

This document provides the product boundaries for the system enhancement. i.e. What

product/system characteristics should be or should not be included within the enhancement. [2]

1.2.1 Relationship to System Development

This is the first work product associated with a new product/project (which can be either a

completely new system or an enhancement to an existing system). It is created before and

intended to serve as the basis for the following [2]:

Risk Analysis

Project Charter

Detailed Requirements Definition

1.3 System Overview

1.3.1 NEXIS

The NOVEC Information System (NIS) is a repository for project planning. The system is run by

NOVEC project planning division. The repository for the data is locally owned and operated by

NOVEC in Gainesville, VA. The NIS is currently in operation providing critical metrics.

The primary purpose of the NIS is to support NOVEC’s project planning mission, by providing

NOVEC with project forecasting as dictated by the Local Data Reporting capabilities of the

counties they serve. Its secondary purpose is to serve as the local data repository of the Project

Planning group.

Presently the system has a documented process for processing land records. This process is

manual in nature, but is augmented by a database. The database is run by an administrator that



7

polls data from several sources and processes the data into useful metrics for project expansion

data. In all cases the data is polled from local sources for each county.

1.3.2 Local Data Reporting

There are two data sources that are useful to the NOVEC identification system: The Loudoun

County Available Land Database (LCAL) and The Loudoun County Online Land Application

Database (LOLA).

1.3.2.1 Loudoun County Online Land Application (LOLA) System The Loudoun Online Land Application (LOLA) database “provides a user-friendly tool to access

information regarding legislative land development applications and provides a format for public

input for active applications” [4]. The database contains all land that is under action from the

Loudoun County Planning Department. This database helps the forecasting model display status

and time frame of Land Application completion and thus project type and predicted start date. It

has a data dictionary that contains the following: Application Type, Application Number,

Application Name, Description, Status, File Date, Acceptance Date, Completion Date, Existing

Zoning, Pin Number, and Tax Map ID.

1.3.2.2 Loudoun County Available Land (LCAL) System The Loudoun County Available Land Database is a list of available land after appropriate zoning

by the local government. It has a data dictionary that contains the following: Marketing Name,

Marketing ID, Zoning Type, Available Square Feet, Available Acres, Development Timeframe,

Corridor, Pin Number, and Tax Map ID.

NIS uses the information from this database to calculate schedule, and forecasted projects that

are yet to come under application.



8

1.3.3 Concept Diagram for Proposed Enhancement

WAN


(NEXIS)

LCAL LOLA

DatabaseStore Collected DataUser Enters QueryProvide Query Results

ApplicationCollect Webpage DataProcess Collected DataNotify User(s) of updates

Terminal UserAdmin

Figure 1. NEXIS process overview

There NIS process will be augmented by NEXIS. It will feature an automated data parser and

integrate with the database infrastructure of NOVEC. The system will be connected to the

internet and pull data from all data sources. This process will automate the database generation

and provide a platform for providing a user base of changes to the state of the project forecasting.

The user base of the system will be updated to: Users and Administrators.



9

2.0 Referenced Documents

1. IEEE Std. 1362-1998 – IEEE Guide for Information Technology – System Definition

– Concept of Operations (ConOps) Document, Institute of Electrical and Electronics

Engineers, Inc., New York NY, 1998

2. Bylaws of the Cooperative, NOVEC Charter, Dale City VA, 2014

3. AQS Submit Automation Concept of Operations, US Environmental Protection

Agency Office of Air Quality Planning and Standards Outreach and Information Division

National Air Data Group, Research Park NC, 2011

4. Loudoun Online Land Application Database,

http://www.loudoun.gov/index.aspx?nid=1078, Loudoun County Government, Loudoun

County VA, 2015

5. Loudoun County Available Land Database,

http://biz.loudoun.gov/index.aspx?nid=150, Loudoun County Government: Department

of Economic Development, Loudoun County VA, 2015



10

3.0 Existing System

This section provides context and background for the subsequent sections. The existing system

is described in order to give a holistic understanding of the existing conditions.

3.1 Background, Objectives, and Scope

NOVEC is one of the largest electric distribution cooperatives in the country. NOVEC

leverages over 25 years of experience in providing electric service to Northern Virginia.

NOVEC's service area covers spans Clarke, Fairfax, Fauquier, Loudoun, Prince William, and

Stafford counties. This service area includes over 155,000 homes and businesses. NOVEC has

grown to support the ever-increasing population in the Northern Virginia area.

Population in Fairfax County has grown by over 100% in the past 40 years. This growth

leads to an increased demand on power suppliers and providers. Increases in commercial

business further add to the increased power demand. At the beginning of the 20th century

approximately 10% of Americans had access to electricity. Many rural areas were left without

access. Cooperatives like NOVEC began to fill the gap between producers and consumers.

NOVEC does not produce the electricity they sell; rather, they purchase the electricity

from power plants and transport it to their customers. This business model requires that NOVEC

purchase electricity prior to production or transportation based on the estimated demand of their

customers. NOVEC relies on predictive demand models in order to supply a constant and cost

consistent product. Forecasting models are used in determining where to place assets and how

much energy to purchase from producers.

3.2 Operational Policies and Constraints

3.2.1 NOVEC Charter

NEXIS will not violate the terms and conditions set forth in by laws of the cooperative charter

[3].

3.2.2 LCAL

Loudoun County Virginia maintains the LCAL data store. The NEXIS system will utilize this

data. NEXIS will conform to all fair use policies of this data which is published for public record

by the Loudon County Government.

3.2.3 LOLA

Loudoun County Virginia maintains the LOLA data store. The NEXIS system will utilize this

data. NEXIS will conform to all fair use policies of this data which is published for public record

by the Loudon County Government.



11

3.3 Description of the Current System

Data on project forecasting is currently supplied by the project manager for each individual

project. The work products are delivered to analysts in a timely format however compilation of

the data into a meaningful forecasting model on project timelines are cumbersome and prone to

real time error based on individual input rather than raw application data. If any gaps are present

in the model then the analyst will need to pursue that data to its own end. This system is outlined

in the figure 2.

NIS Project Forecasting System

Project Managers

Project Managers

Data Store

Analysts

Figure 2. Existing Forecasting System

The process is manual in nature and can be cumbersome. There is very little automation and in a

service oriented company that needs to maintain a high level of customer interaction this can

lead to inaccurate predictions of project intent and therefore inefficient control for NOVEC’s

customers. A change in the current system with increased automation is therefore justifiable.



12

4.0 Justification For and Nature of Changes

4.1 Justification of changes

NOVEC has successfully served the community for over 25 years. Their ability to meet

consumer demand and generate profits is directly related to their ability to forecast future

demand. Reliable forecasting relies on accurate data and complete models. However, growing

demands and incomplete models can put this success at risk.

The jurisdictions within NOVEC's service area, including Loudoun County and Fairfax County,

have experience high population growth rates over the past decade. Population growth leads to

increased development of residential, commercial, and industrial facilities. Energy demands

increase as new developments are connected to the power grid. Large power consumers such as

high-density housing units have significant impacts on the energy demands of a locality.

Without a predictive model this increased demand will not be identified until after the unit has

come online and the demand is observed in the operational system. This is a source of

significant risk for NOVEC.

The current models employed by NOVEC use location and development category to model

power demands. Buildings are categorized based on use and size to estimate the individual

usage characteristics. Recent research has explored categorizing properties based on historical

usage trends. Regardless, the current forecasting models neglect to incorporate future

developments into the estimates. This is a significant shortfall in an area that is constantly

experiencing growth.

NOVEC requires a system that is capable of collecting data on current development projects.

This system will be integrated into legacy systems and models. The data collected by this

proposed system will augment current forecasting models. NOVEC will develop a more

accurate understanding of market demand by integrating the development data into the

forecasting.

4.2 Description of Desired Changes

The following capabilities outline the desired behavior of the proposed system.

Capabilities:

Capability to provide end-to-end automated data collection process

Capability to scale to accommodate the collection and storage of the predicted future

service area

Capability to ensure that data is free of corruption and abnormalities

Capability to provide access to stored data

Capability to enforce restrictions against data altering

Capability to manage the creation of reports formatted to integrate with legacy systems

Capability to manage the creation of automatic audits of data updates

Capability to integrate with legacy hardware infrastructure

Capability to provide restricted user access to modify data



13

5.0 Concepts for the proposed system

This section describes the proposed system in detail including background, constraints, and user

classes.

5.1 Background, objectives, and scope

The proposed system was solicited by NOVEC to provide additional modeling capabilities.

NEXIS will expand the capabilities of the current models employed by NOVEC. NOVEC has

the ability to use data on ongoing development projects to refine demand forecasts. This system

will enable them to easily access up to date development data through a single centrally located

data store. NEXIS has four main functions; collection, processing, storage, and reporting.

5.2 Operational Policies and Constraints

NEXIS is required to integrate with all existing NOVEC operational policies.

5.3 Description of the Proposed System

NEXIS is an automated data collection tool that collects, stores, and reports data to the user.

This system eliminates the time prohibitive task of collecting thousands of data points about

ongoing construction projects by hand. NEXIS uses publicly available data from Loudoun

County to populate a database and display data to users for use in predictive demand models.

The system provides three high level capabilities data collection, data storage, and data reporting.

The first required capability is data collection. NEXIS is capable of parsing online sources and

processing the data prior to storage. The processing will require that the data be checked for

content, anomalies, and uniqueness. NEXIS first flags any missing data fields from a newly

detected record and attempts to fill in missing fields with data available from previously stored

records for the same project. Next the system checks for any anomalies against previous records.

These anomalies are flagged for user review. Finally the system verifies that the record is

unique. If a record exists that contains the identical data for the same project then the new record

is not added to the database. The data processing conducted by NEXIS insures that all data

stored in the system is as accurate and complete as technically feasible.

The second capability demonstrated by NEXIS is data storage. NEXIS stores all applicable data

in a database for ease of access by users. The storage of collected data eliminates the need to

constantly collect data from the various online sources. Additionally, storing data locally

increases the speed of queries. This provides easier access to the data needed by the predictive

models.

The final capability of NEXIS is the data reporting capability. The data reporting capability will

provide an automated process for providing the forecasting information to the NEXIS user. The

data report will be sufficiently detailed to accurately populate the forecasting model.



14

5.3.1 System Components

NEXIS is comprised of both physical components and interfaces. The physical systems and

software can be divided into two main components.

Web Scraper:

The data collection and processing component scrapes project information from publicly

available websites on a configurable interval. The web scraper will have an interface that needs

to be deployed. The web scraper will have a configurable timer that will pull data at a predefined

interval. In addition server hardware will be needed to deploy the web scraper.

Data Store:

The second component is the data store. This component provides the storage and access

capabilities needed to generate reports used as model imports. The data store will consist of a

database, and the hardware necessary to deploy the database. The data store hardware can be the

same hardware used to deploy the web scraper.

5.4 Modes of Operation

NEXIS has three operational modes:

Nominal

Degraded

Offline

Nominal describes the system condition when all functions are performed without incident. This

is the normal operational mode. In the operational mode the system will collect, process, and

store all identified data.

The degraded mode indicates that the collection process is currently unavailable. In this mode

the system is still capable of providing access to the data and generating reports.

Offline describes the system condition when one or more components are nonfunctioning and

render the system unavailable. This mode indicates that the data is inaccessible and prevents the

generation of reports.

5.5 User Classes

The users for this system are considered actors who interact with the system. The user will

interact with the system from the perspective of their class. The two major user classes for this

system include General Users and Administrators.

General User:

This user will access the system using a username and password. They access data records and

generate reports. This user does not have the ability to alter records stored in the database.

Administrator:



15

Contracted IT services data steward. Has read/write access to the database in addition to

administrative functions.

Analyst:

This user will access the system using a username and password. They access data records and

generate reports. This user does have the ability to alter records stored in the database.

5.5.1 Organizational Structure

There is no unifying organizational structure for the user base as a single person within the

Project Planning organization can have one or both roles within the NEXIS process.

5.5.2 Profiles of User Classes

See Section 6 for more information on Responsibilities.

1. General User:

a. Who: Non-privileged user. Typically a person who has a need to access the

system without privileges.

b. Access: Read-only access to the database

c. Responsibility: Logging in, processing data, triggering monthly database updates,

requesting updates to incorrect records

2. Analyst:

a. Who: Privileged user. Can perform both user functions and database

administrative functions. Typically a person who has extensive knowledge of the

system data processing.

b. Access: Read/Write access to the database

c. Responsibility: Responsibility: Logging in, processing data, monthly database

updates, updates to incorrect records

3. Administrator:

a. Who: Administrative user. Can perform both user functions and database

administrative functions. Typically with backend knowledge that can maintain

database, network and software. Third party IT support can also fill this role.

b. Access: Read/Write access to the database and administrative functions

c. Responsibility: Logging in, manually updating database, assigning privileges,

system startup, system shutdown, reading log files, manually backing up database



16

6.0 Operational Scenarios

The NEXIS ConOps describes the capabilities desired by the NEXIS users. Subsequent sections

describe the primary capabilities and success scenarios for NEXIS. This section is not intended

to describe every system scenario. This section provides the main scenarios needed to reach the

expectations of the main stakeholders and provide the context for developing the system design.

6.1 User Goal Use Case Diagram

No Connection

No Data Integrity

Collect Development

Data

Generate Reports

Invalid Input

Log

Startup

Shutdown

Reconfigure<<extends>>

<<extends>>

<<extends>>

Condition: {Search

Condition invalid format}

Condition: {Status is

not connected}

Condition: {Data

Error}

No Portal Connection

<<extends>>

Condition: {Status is not connected}

User

Admin

LCALLOLA

<<extends>>

Login

Assign Priveleges

Amend Data Entry

Manually Backup

Database

Analyst

Figure 3. Use Case Diagram

The detailed descriptions of the use cases and their interaction. The end goal is to provide the

user base with an automated process to update the NEXIS database, extract information from it

and manually regulate the data if necessary. The nominal use cases in bold are described below.

The use cases available to the user are “Collect Development Data” and “Generate Reports”. The

use case with Admins as the primary actor is “Amend Data Entry”.

6.2 User Goal Use Case Descriptions

6.2.1 Scenario 1: Collect Development Data

6.2.1.1 Description This scenario describes one of the main capabilities of the proposed system, the ability to scrape

data from government data stores.



17

This scenario is triggered by manually by the analyst user. The system then checks for a nominal

connection to the government data sources and to the database. The database updaters send the

available CSV file.

Next, the system scrapes all available data from the data store. The system parses the data and

renders it into a standard format. This enables the data to be processed. During this step the

system will compare the collected data against existing data entries. The system will flag any

entries that have matching project IDs and conflicting data fields. These data fields include

address, project owner, and any other field identified during the system design process. Users

will be notified of any anomalous entries that have been flagged.

The system will then store all new entries in the database. The records will be formatted to meet

the requirements of the database design. The system will then notify all users of any new entries

that have been added to the database.

6.2.1.2 Sequence Primary Actor(s): Analyst

Pre Condition(s):

New database update is received

Post Condition(s):

Database are populated with all records applicable

Report on data integrity is delivered

Derived fields are created

Database is updated

Main Success Scenario:

1. Analyst adds new CSV to repository

2. Analyst sends request for database update

3. System parses data

4. System processes data integrity report

5. System updates database according to new raw file

6. System processes derived fields

7. System creates “List of Records” into CSV format

8. System creates change report for database

9. System sends entire current “List of Records” in CSV format, to entire user base via

email, with the following in body:

a. Number of new records

b. Number of new records with missing data fields

c. Output of new records with missing data fields

d. Number of updated records

e. Number of removed records

10. Analyst processes data, exit

Extensions:

4. (a) No data integrity

a. Scraper checks Tax ID against older records

b. Website data record returns different Tax ID



18

c. Scraper reports data as updated record

5. (a) No data integrity

d. Scraper checks Tax ID against older records

e. Website data record returns different Tax ID

f. Scraper reports data as updated record

4. (b) No data integrity

a. Scraper checks Location against older records

b. Website data record returns different Tax ID


4. (c) No data integrity

a. Scraper checks Project Size against older records

b. Website data record returns different Project Size


4. (e) No data integrity

a. Scraper checks format of field against older records

b. Website finds invalid format in raw database

c. Field is reported as “NULL”

d. Error is recorded in log file

e. Record is allowed into database

6.2.2 Scenario 2: Generate Reports

6.2.2.1 Description This scenario describes the capability to generate reports from the data stored in the system

database. This will trigger a user query for data inside of the updated database.

This scenario is triggered by a user requesting a report from a set of predefined queries. The user

first logs into the system using a valid username and password combination. Next, the user

selects a report from a list of defined reports. The system then processes the request and

generates a report containing the requested data. The data is formatted such that it can be

ingested by legacy modeling systems.

6.2.2.2 Sequence Primary Actor(s): User, Analyst

Pre Condition(s):

User need for interim data or out of cycle

Post Condition(s):

Input parameters of made query are correct


1. User/Analyst accesses the database

2. User/Analyst enters query in the proper format

3. Database returns all applicable record values

4. User/Analyst processes data, exit

Extensions:

1. (a) Invalid Input

a. User enters query parameters



19

b. User has entered incorrect format for query

c. System returns “error: retry <display of correct format>” message

2. (a) Invalid Input

a. User enters query parameters

b. System sends query to database

6.2.3 Scenario 3: Amend Data Entry

6.2.3.1 Description This scenario describes the capability to amend erroneous data records. Analyst needs to

manually update the database. This can be caused by a NULL field or other error identified by

the integrity report. In addition if a user request is given to manually update a field the

administrator will research and execute as appropriate.

This scenario is triggered by a user identifying an inaccurate data record. The user would

request that an administrator edits the entry. The administrator would log into the system using a

valid username and password combination for an account with administrative privileges. The

administrator would then revise or redact the flawed data field. The system will allow the

administrator to alter multiple entries during a single session.

6.2.3.2 Sequence Primary Actor(s): Analyst, User

Pre Condition(s):

NULL field has been raised in the data integrity check

User request to update database

User has researched proper value

Post Condition(s):

Database records are updated


1. User identifies inaccurate record

2. User provides corrected value to Analyst

3. Analyst access database with analyst privileges

4. Analyst issues command to update records

5. Analyst checks database record to ensure consistency, exit

Extensions:

4. (a) Analyst needs to remove record

a. Admin issues command to remove record

4. (b) Analyst needs to add new record

a. Admin issues command to create new record

b. Admin issues command to fill in all applicable fields of the record

4. (c) Analyst needs to change record

a. Admin issues command to change record field



20

7.0 Summary of Impacts

7.1 Operational Impacts

7.1.1 User Interface for Query

The user interface will need to be coded. This will have the following impacts:

1. Users will need training on the operation of the interface

2. Hardware for data store will need to be reprogrammed to allow new interfaces and

processes

3. Deployment plan will need to be created for software install

7.1.2 User Account Registration

The system will need user accounts and administrator’s accounts. The system will use the user

accounts registration process. It is anticipated that the IT department will not be impacted.

7.1.3 Log File Reporting

The system will use the local backup process for log file reporting. This will require local

database nodes to be updated with the data store for NEXIS log file reports.

7.1.4 System Backup

The system will use the NOVEC backup process for their systems. The local nodes will need to

be reprogrammed to create the infrastructure for these backups.

7.2 Organizational Impacts

7.2.1 NOVEC Headquarters

1. The NOVEC headquarters will house the software required for NEXIS operation.

2. It will also house the user base

3. Hardware for data store will need to be reprogrammed to allow new interfaces and

processes

7.2.2 NOVEC Project Planning

1. Will need training on the user interface and administrator functions

7.2.3 NOVEC IT

1. will need to deploy the NEXIS software

2. will need to deploy the NEXIS database

3. will need to update data store for error reporting

4. will need to update data store for system backup

7.2.4 NOVEC Regional Offices

It is anticipated that NOVEC regional offices will not be receiving reports from project planning

and will therefore be impacted.



21

7.3 Impacts During Development

7.3.1 Firewall

The NOVEC firewalls will need to be reconfigured to allow incoming data from LOLA and

LCAL. The new incoming data will be deployed on NOVEC servers.

7.3.2 Permissions

NEXIS will use a web scraper to pull publicly available data from the LOLA and LCAL. Proper

permissions will be required to obtain and use this data.



22

8.0 Analysis of the Proposed System

8.1 Summary of Improvements

8.1.1 Increased Efficiency of the Project Planning Agency

8.1.2 Increased Accuracy

The NEXIS system will be an automation process. It will increase accuracy of the system by

removing human error from the processing of records from the data sources. This will free up

resources to process data and develop metrics for project planning and deployment opportunities.

8.2 Disadvantages and Limitations

8.2.1 Increased Cost to the Project Planning department

The NEXIS system will need to be developed, and deployed. In addition all organizational

impacts will need to be addressed resulting in cost increases to operations. Cost-Benefit analysis

may be useful to analyze trade-offs of capabilities

8.3 Alternatives Considered and Trade Offs

8.3.1 Lease of Data

The web scraping device may not be useful as a system component. Investigation revealed that

the address space of the data source LCAL will likely be changing shortly after the deployment

schedule. In addition the API for google earth may impact Subdivision Approvals and LOLA as

well. The total of this change will need to be analyzed and a lease of a direct feed to the data may

be considered at increased cost to system deployment.

8.3.2 Manual Processing of Data

A formalized manual data processing work flow may also be considered.



23

9.0 Appendices

9.1 Acronyms and Abbreviations

Acronym/ Abbreviation

Definition

LCAL Loudoun County Available Land System

LOLA Loudoun County Online Land Application System

NEXIS NOVEC Expansion Identification System

NIS NOVEC Identification System

NOVEC Northern Virginia Electric Cooperative