Running head: LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
Lab 2 - Power Play Product Specification Outline
Team Black
Addy Alago
Old Dominion University
CS411W
Janet Brunelle
January 8, 2017
Version 1
1
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
2
Table of Contents
1 Introduction .....................................................................Error! Bookmark not defined.
1.1 Purpose..................................................................................................................... 4
1.2 Scope ........................................................................................................................ 5
1.3 Definitions, Acronyms, and Abbreviations .............................................................. 7
1.4 References ................................................................................................................ 8
1.5 Overview .................................................................................................................. 9
2 General Description ...................................................................................................... 10
2.1 Prototype Architecture Description........................................................................ 10
2.2 Prototype Functional Description .......................................................................... 12
2.3 External Interfaces ................................................................................................. 15
Figures and Tables
Figure 1 Current Process Flow ........................................................................................... 5
Figure 1.1 Improved process flow ..................................................................................... 7
Figure 2 Major Functional Components ........................................................................... 12
Figure 2.1 Landing Page ................................................................................................... 13
Figure 2.2 Registration Form ............................................................................................ 14
Figure 2.3 Administrator Panel Mockup ........................................................................... 14
Figure 2.4 Analyst Panel Mockup ..................................................................................... 15
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
3
Table 1 Feature comparison between full product and prototype .... Error! Bookmark not
defined.
Lab 2 - Power Play Product Specification Outline
1 Introduction
Every major corporation relies on history to make decisions. This decision making
process can take many forms, from quarterly earnings reports, to performance metrics. These
forms certainly play a big role in predicting future behavior and making decisions. A company
may make what appears to be a minor change in a product, only to find that it causes an
unexpected downturn in that product’s sales. Decisions are honed and fine-tuned iteratively
over time. The problem, of course, is that history takes time to play out.
In 2002, the United States Army had an interesting idea. They developed America’s
Army, a video game of the first person shooter genre. The game was built with the intention of
enticing teenagers to consider the army as a possible career path. Although originally meant as a
recruiting tool, it was quickly realized that this game could be used as a tool for simulation and
training. The army was able to build multiple scenarios. The scenarios were run multiple times
allowing the army to study the different decisions made by players. They could also add
variables to see how it would affect the outcomes of these scenarios. The result was obviously
beneficial. In a relatively short amount a time, the army could gather multiple data points about
how certain soldiers would handle different scenarios or how the same soldier would handle
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
4
similar scenarios. This allowed them to develop plans which would lead to predictable best
outcomes.
Power Play seeks to be a similar platform for the power industry and other industries with
similar simulation needs. Power Play was conceived and developed by the Old Dominion
University 2016 CS 410 group for Dr. Mamadou Seck. Dr. Seck developed the Spark simulation
engine, an engine that models and simulates power plant data and scenarios. Power Play seeks
to provide a gamified front end for power plant management decisions. These decisions will be
fed into the Spark Simulation Engine to provide analyzable results that can be used by power
plant managers to determine best practices. The simulation allows plant managers to accumulate
multiple data points over multiple users, and, through analysis, these data points can guide future
decisions.
In order for this platform to be successful, it must be easily accessible and user friendly.
The web-based platform chosen for this project allows it to be used across any device with a
browser. The platform will also provide analyzable results and allow for multiple scenarios so
that data can be collected for decisions across a variety of situations.
Power Play is being developed by Team Black, composed of project manager Addy
Alago and team mentor Nathapon Songchiakyou. David Heeschen is the database engineer for
the project. The research team consists of Terrel Kittrell, Ryan Rusnak, and Jack Elder.
Algorithm and UI development is led by Trai Corte and Nicholas Benfield. Addy Alago also
serves as the web administrator for the team website.
1.1 Purpose
The purpose of Power Play is to create a front end for the Spark simulation engine. This
will allow players, analysts, and administrators to log in and use the program for the purposes of
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
5
playing rounds of simulation, analyzing the round’s results, and administrating the scenarios.
The intended user community for the product is Dominion Power staff. By playing the
simulation, employees learn more about the decision-making process and its effects on the
environment, and company finances. Analysts will be able to use the system to analyze the
effects of decisions made and use that to more accurately forecast effects.
The product will not simulate any of the data as this will be handled by the Spark engine.
The product will create an interface to interact with the simulation engine.
1.2 Scope
The Power Play product will be used by Dominon Power employees. Power Play will be
open source and adaptable for use by other industries. Players will be able to get a glimpse into
the factors that go into decision making, and the impact of those decisions on company finances
and the environment which can help with training and preparation for management roles within
Dominion Power. The current process flow is detailed in the diagram below along with
examples on the types of decisions Dominion Power faces during planning.
Figure 1. Current Process Flow
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
6
This system is not necessarily ineffective. In fact, because of its reliance on known
historical outcomes, it is a very safe way to operate. Decisions reached will not have a large
variance in effects from their historical counterparts. The system does, however, preclude the
possibility of experimentation in decision making. This is good because experimentation can also
cost money, and time.
The system is also rigid and inflexible. This system does not deal with rapid changes
particularly well. If new legislation is enacted, it may change the impact of some of the decisions
made for the year, and, in these cases, decisions must be made ad-hoc to deal with the new
variables. This would render any decision-making model obsolete. In a study conducted by
Strategy&, 57 percent of global energy company executives said “current market models are
already broken and the need for new approaches to deal with a rapidly altering and volatile
business landscape is urgent (Earl, Leslie, Shuva, & Daniel, 2015).” A survey conducted by
McKinsey Global found that more decisions in an average corporation are made outside of any
annual process than within one (Garbuio, Lovallo, & Viguerie, 2009).
By moving decisions from an annual process, to a real-time simulator, Power Play
presents two main benefits. Several different scenarios can be modeled and tested through many
different variations of decisions in a short amount of time. The old model is reliant upon
historical data. If a new situation comes about (for example a new piece of legislature is passed),
decisions are effectively made with no baseline. Power Play can create a simulation around the
new piece of legislature. Players can then experiment with different ways to tackle the problems
presented by the legislature. This allows a baseline to be generated in a very short amount of
time, instead of years.
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
7
Figure 1.1. Improved Process Flow
The other benefit is that experimentation on different scenarios can be done quickly and
with little expense. A power company may not want to make a potentially risky or untried
decision to tackle a problem due to the cost involved with experimenting in a real environment.
Power Play allows those decisions to be trialed at no expense.
In the above figure, you can see where the simulation engine replaces decisions in the old
process flow with simulated decisions. The annual process is then simulated and replaced with a
simulation of changes that would occur over the course of a year. The goal is to reduce the time it
takes to see the outcome of decisions by simulating the outcome. This will then supply
analyzable results for future decisions.
1.3 Definitions, Acronyms, and Abbreviations
Administrator GUI: the web page interface for all approved administrators.
Analyst GUI: the web page interface for all approved analysts. This section will show reports
and graphs generated by gameplay data.
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
8
Back-end: The portion of Power Play not visible to end-users. This includes the Spark
Simulation Engine and all programming needed to interface with the engine.
Front-end: Portion of application with which end users interact with directly.
Power Play: Power Play refers to the combination of the simulation engine, and the web based
front end as well as the back-end code needed for the two systems to interact.
Planning Phase: The first phase of a round of gameplay in which decisions are made by
changing pre-existing variable values in response to the scenario presented.
Presentation Phase: The first phase of a round of gameplay in which the scenario is presented
to the player in the form of a description, and a set of variable values.
Simulation Phase: The third phase of a round of gameplay in which the user’s decisions in the
form of changes made to variables are submitted to the simulation engine. The engine
then returns results to the player.
Simulation Round: A round of gameplay marked by a cycle of 3 phases of gameplay: the
presentation phase, the planning phase, and the simulation phase.
Spark Simulation Engine: Spark Simulation Engine is a system being created to model and
simulate different power distribution scenarios and events. This will provide the back end
to the Power Play Project.
1.4 References
Armin, R. (2017). Flask Overview. Retrieved February 22, 2017, from Flask.org:
http://flask.pocoo.org/
Dominion Power. (2017, February 4). Dominion Power company Profile. Retrieved February 20,
2017, from https://www.dom.com/about-us/company-profile
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
9
Earl, S., Leslie, H., Shuva, C., & Daniel, W. (2015, November 20). Retrieved February 20, 2017,
from Strategy&: http://www.strategyand.pwc.com/reports/utilities-preparing-for-growth
Garbuio, M., Lovallo, D., & Viguerie, P. (2009, January). Mckinsey & Company Strategy &
Corporate Finance. Retrieved February 21, 2017, from
http://www.mckinsey.com/business-functions/strategy-and-corporate-finance/ourinsights/how-companies-make-good-decisions-mckinsey-global-survey-results
Google. (2017). Google.com. Retrieved February 20, 2017, from Google Maps:
https://enterprise.google.com/maps/products/mapsapi.html
MongoDB, Incorporated. (2017). https://www.mongodb.com/. Retrieved February 20, 2017, from
https://www.mongodb.com/: https://www.mongodb.com/
Python Software Foundation. (2017). What is Python? Executive Summary. Retrieved February
20, 2017, from python.org: https://www.python.org/doc/essays/blurb/
Salvatierra, J. (2017). REST APIs with Flask and Python. Retrieved February 20, 2017, from
Udemy.com: https://www.udemy.com/rest-api-flask-and-python/
Team Black. (2017). Lab 1. Norfolk: Old Dominion University.
Team Black. (2017). Lab 2. Norfolk: Old Dominion University.
1.5 Overview
This product specification provides the hardware and software configuration and
capabilities and features to fully implement the Power Play prototype. This prototype will not
need the use of any external interfaces. The information that is provided in the remaining
sections of this document includes a detailed description of the hardware and software
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
10
configuration and capabilities and features. The product specification requirements provided in
Lab II Section 3.1 can be found in a separate document.
2 General Description
Power Play is a web-based system through which Dominion Power employees can
simulate the decision-making process used by managers. Players will log in, and take the role of
a CEO. They will be presented with a scenario and a set of variables representing the state of
several regions, and power plants in those regions prior to the scenario. Based on the scenario
presented, a player must make changes to these region and power plant variables and attempt to
get the best possible outcome through the decisions they make. Once these changes are
submitted, the Spark Simulation Engine will evaluate the changes and simulate an outcome to be
displayed back to the player.
The prototype will have 3 modules: the gameplay module, the analyst module, and the
administrator module. The gameplay module will allow players to play through simulations. The
administration module which will allow users with administrator privileges to alter scenario
values and edit accounts. The analyst module will allow users with analyst privileges to view
statistics on gameplay rounds.
2.1 Prototype Architecture Description
The Power Play prototype will have most of the same structure and feature set as the realworld product. See table 1 below for details.
Features
Player Features
Plant retirement
Plant refurbishment
Plant construction
Viewable resources
Viewable Environmental Impact
RWP
Prototype
✔
✔
✔
✔
✔
✔ Plant can be deactivated
✔ Plant can be refurbished
✔ New plants can be constructed by player
✔ Resources will be displayed in top info bar
✔ Viewable by plant, state and region displays
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
Features
Viewable Earnings
RWP
✔
Prototype
✔ Viewable on top info bar
Administrative Features
Create game scenarios
Create and remove player accounts
Reset collected data
Access player game results
Player update notification
✔
✔
✔
✔
✔
! partially implemented
✔ Accessible through admin controls
✔ Accessible through admin controls
! partially implemented
✔
Analysis Features
Viewable decision data
Viewable event collection data
Viewable data collection by type
Downloadable data by region
Downloadable data by date
✔
✔
✔
✔
✔
✔ Accessible through analyst page
✔ Accessible through analyst page
✔ Accessible through analyst page
✔ Accessible through analyst page
✔ Accessible through analyst page
Testing Features
Modifiable scenario data
✔
✔ Accessible through admin page
11
Table 1 feature list
Power Play is being developed as a web app. The front-end administrator and analyst
modules will be written in HTML, PHP and Javascript. The gameplay module will use the Unity
engine.
Power play will run on an Ubuntu web server hosted by ODU. Database storage will use
Postgresql. Lastly, the Spark Simulation Engine, provided by Dr. Mamadou Seck, will drive all
simulation calculations but will not be completed in time for the prototype. All simulation data
and results will be hard coded for the purposes of the prototype.
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
12
Figure 2. Major Functional Components
2.2 Prototype Architecture Description
When users visit the Power Play page, they will be prompted to create a new account or
log in. Once a new account is created, an administrator will be alerted of a new user via email
and must approve the user. At this point the administrator can also elevate the user to an analyst
or administrator. Once the account is properly activated, the user can log in and will be greeted
by a profile page offering basic information on previous game play, as well as menu options to
play the game. If a user is an administrator, they will have options to navigate to the
administrator module. Likewise, if they have analyst permissions they will have access to that
module via a navigation option.
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
13
Figure 3.1. Registration Form
The gameplay module is being constructed by a sub team of Team Black, for details on
that module see Lab 1 Section II submitted by Trai Corte, Nicholas Benfield, Or Jack Elder. The
user login landing page will be sparse for the purposes of this prototype. It will offer options to
play a game, log out, or edit account information such as email and password.
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
Figure 4.2. Landing Page
The admin module will be able to view any users in the system and see their current
permissions and activation status. The administration can disable or delete users and their data.
Figure 5.3. Admin Panel Mockup
14
LAB 2 – POWER PLAY PRODUCT SPECIFICATION OUTLINE
15
The analyst module will allow users with analyst permissions to view gameplay data.
For the purposes of the prototype the data will be an aggregate formed of all gameplay data for
all players and all simulations. The real-world product will develop more specific reporting per
player, per region, and per simulation.
Figure 6.4. Analyst Panel Mockup
Our database schema is described in detail in section 3.1 of Lab 2.
2.3 External Interfaces
No external Interfaces will be needed to construct this prototype.
3 Specific Requirements
The functional requirements of the Power Play prototype are in a separate document, Lab
II section 3.1. This contains all requirements necessary to complete the prototype.