North Slope Decision Support System First Stakeholder Workshop January 20-21, 2009 Anchorage, Alaska.

Slides:



Advertisements
Similar presentations
Final Workshop September 20, 2012 Anchorage, Alaska.
Advertisements

North Slope Decision Support System nsdss.ine.uaf.edu Presented at the DataNet Federation Consortiums DataGrid Sessions, April 2013 Presented by Jack Hampson/Stephen.
Global Congress Global Leadership Vision for Project Management.
Watershed Approaches and Community Based Planning
3 rd Stakeholder Workshop April 27-28, 2011 Fairbanks, Alaska.
Alaska Native Education Program (ANEP) Technical Assistance Meeting September 2014 Sylvia E. Lyles Valerie Randall Almita Reed.
May 17, Capabilities Description of a Rapid Prototyping Capability for Earth-Sun System Sciences RPC Project Team Mississippi State University.
Requirements Specification
DETERMINANTS OF DATA USE Session 2. Session Objectives  Explain the data-use conceptual framework  Highlight the determinants of data use  List potential.
Clarity on the performance of IT Metricus at a Glance Metricus Metricus has been acknowledged for breaking new ground on IT performance management and.
Challenge Questions How good is our operational management?
WRAP Technical Support System Project Update AoH Call October 19, 2005.
Demand Planning Scenario Overview
ENVIRONMENTAL DATA MANAGEMENT & SHALE GAS PROGRAMS INTERNATIONAL PETROLEUM ENVIRONMENTAL CONFERENCE NOVEMBER 14, 2013.
©© 2013 SAP AG. All rights reserved. Resource Management Scenario Overview Administering Resources Scenario Explorer Scenario Description The following.
State of Kansas Statewide Financial Management System Pre-Implementation Project Steering Committee Meeting January 11, 2008.
The BIM Project Execution Planning Procedure
What is Business Analysis Planning & Monitoring?
ArcGIS Workflow Manager An Introduction
Enterprise IT Decision Making
AICT5 – eProject Project Planning for ICT. Process Centre receives Scenario Group Work Scenario on website in October Assessment Window Individual Work.
1 Beyond California Water Plan Update 2005 California Water and Environmental Modeling Forum Annual Meeting, March 3 rd, 2005.
Systems Analysis And Design © Systems Analysis And Design © V. Rajaraman MODULE 14 CASE TOOLS Learning Units 14.1 CASE tools and their importance 14.2.
DATA FOUNDATION TERMINOLOGY WG 4 th Plenary Update THE PLUM GOALS This model together with the derived terminology can be used Across communities and stakeholders.
Basics of OHSAS Occupational Health & Safety Management System
Chapter 2 The process Process, Methods, and Tools
Page 1 MODEL TEST in the small GENERALIZE PROGRAM PROCESS allocated maintenance changes management documents initial requirement project infrastructure.
Low Flow Analysis & Water Use Plan Science & Community Environmental Knowledge Fund Forum June 10, 2004 Barry Ortman Diversified Technical Services Dawson.
Presented by: Pechanga Environmental Department Designing and Managing a Recycling Program Source Reduction Strategies for Tribal Solid Waste Programs.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Business Analysis and Essential Competencies
Certification & Training Assessment Group History & Current Activity North Central Region Pesticide Education & Certification Workshop June 2002.
Stock Assessment Peer Review: Findings and Actions Shannon Cass-Calay Caribbean Fishery Management Council April 2015 Southeast Fisheries Science Center.
Unit 3. demonstrate the ability to use subprograms within computer programs; use a variety of problem-solving strategies to solve different types of.
GBA IT Project Management Final Project - Establishment of a Project Management Management Office 10 July, 2003.
Controlling (CO) SAP University Alliances Authors Bret Wagner
Creating a Shared Vision Model. What is a Shared Vision Model? A “Shared Vision” model is a collective view of a water resources system developed by managers.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
MESH UK Workshop 19 October 2006 Introduction Dr Paul Gilliland Marine Policy Adviser and MESH Partner Lead Natural England.
Global Forest Observations Initiative Methods and Guidance Portal SDCG – Oslo – 24 th October 2014.
1 Thank you for visiting our site and welcome to the “Introduction to ISO 22000” Presentation that you requested. For more information.
CHECKPOINTS OF THE PROCESS Three sequences of project checkpoints are used to synchronize stakeholder expectations throughout the lifecycle: 1)Major milestones,
Software Development Cycle What is Software? Instructions (computer programs) that when executed provide desired function and performance Data structures.
1 © 2005 course technology1 1 1 University Of Palestine Chapter 5 (Cont.) Scoping the IT Project with System Use Cases.
Chapter 14: Using the Scalable Decision Process on Large Projects The process outlined is meant to be scaleable. Individual steps can be removed, changed,
Example Template for Project Presentation
Project Portfolio Management Business Priorities Presentation.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Copyright © 2013 by The McGraw-Hill Companies, Inc. All rights reserved. McGraw-Hill/Irwin Business Plug-In B2 Business Process (on OLC)
Consultant Advance Research Team. Outline UNDERSTANDING M&E DATA NEEDS PEOPLE, PARTNERSHIP AND PLANNING 1.Organizational structures with HIV M&E functions.
Supporting Community Participation in U.S. Arctic Ocean Governance Strengthening Institutions Strategies for Cooperative Management in the Marine Environment.
 CMMI  REQUIREMENT DEVELOPMENT  SPECIFIC AND GENERIC GOALS  SG1: Develop CUSTOMER Requirement  SG2: Develop Product Requirement  SG3: Analyze.
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
1 Community-Based Care Readiness Assessment and Peer Review Overview Department of Children and Families And Florida Mental Health Institute.
Team Skill 3 - Defining the System (Chapters of the requirements text ) Sriram Mohan 1.
PRESENTATION TO PORTFOLIO COMMITTEE ON SPORT AND RECREATION SPORT INFRASTRUCTURE.
BUS OPERATOR WORKSTATION PROCUREMENT TEAM TRAINING T O ENHANCE BUS OPERATOR ERGONOMICS, HEALTH, AND SAFETY A TRAINING TEMPLATE FOR TRANSIT AGENCIES [ADD.
Session 2: Developing a Comprehensive M&E Work Plan.
Using Assessment to Achieve Shalom PLANNING AND IMPROVEMENT.
©© 2013 SAP AG. All rights reserved. Product Development Scenario Overview Open Legend Project Manager Scenario Description The following business roles.
Info-Tech Research Group1 Info-Tech Research Group, Inc. Is a global leader in providing IT research and advice. Info-Tech’s products and services combine.
Developing a Monitoring & Evaluation Plan MEASURE Evaluation.
Towards a dependable and sustainable National IT Infrastructure MANAGING IT INFRASTRUCTURE ASSETS: IMPLEMENTATION NEEDS.
Presented for discussion with Implementation SIG Heather Grain.
Monitoring and Evaluating Rural Advisory Services
Product Development Scenario Overview
CLINICAL INFORMATION SYSTEM
Resource 1. Evaluation Planning Template
Introduction to the PRISM Framework
WORK STREAM TEAM DELIVERABLES
Presentation transcript:

North Slope Decision Support System First Stakeholder Workshop January 20-21, 2009 Anchorage, Alaska

Workshop Overview Introductions Project description Workshop objectives Designing the NSDSS through usage scenarios Usage scenario 1: Lake withdrawal permitting Did we get it right? Usage scenario working groups

Introductions Project Team –Amy Tidwell, University of Alaska Fairbanks –Bill Schnabel, University of Alaska Fairbanks –Kelly Brumbelow, Texas A&M University –Stephen Bourne, PBS&J –Leslie Gowdish, PBS&J –Erica Betts, University of Alaska Fairbanks –Arun Aryasomayajula, Texas A&M University –Jim Haleblian, Algoloma Systems

Introductions Stakeholder participants…

Project Description We all have a stake in the North Slope Development of North slope resources requires careful planning that includes all stakeholders. The North Slope Decision Support System (NSDSS) will provide a common forum for North Slope planning and management. The initial NSDSS application centers on environmentally responsible oil and gas exploration. This is a 3 year project, funded by the DOE, National Energy Technology Laboratory.

Decision Support System Project Description Anatomy of a Decision Support System Information System Natural Systems Models Planning and Management

Project Description: Physical Plan Alaska Data Stores On-Going Remotely Sensed Data Collection NorthSlopeDB Enterprise GeoDatabase National Data Stores On-going Field Data Collection NorthSlopeDSS Workbench NorthSlope Stakeholders NorthSlopeDSS Workbench Exploration Team NorthSlopeDSS Workbench Oil Company Planners NorthSlopeDSS Workbench Research Team Cache

Workshop Objective Alaska Data Stores On-Going Remotely Sensed Data Collection NorthSlopeDB Enterprise GeoDatabase National Data Stores On-going Field Data Collection NorthSlopeDSS Workbench NorthSlope Stakeholders NorthSlopeDSS Workbench Exploration Team NorthSlopeDSS Workbench Oil Company Planners NorthSlopeDSS Workbench Research Team Cache Define how to build the workbench.

What am I doing here???? To help define the requirements for the workbench –What are the most important decisions? –What is the existing process for making those decisions? –Can the process be improved? How? –What is the role of technology? –How can the workbench facilitate the decision-making process? –How will you use the workbench?

NSDSS Development Timeline Stakeholder collaboration throughout Outcomes of this workshop drive rapid prototype development of next 12 months

Designing the NSDSS through Usage Scenarios

Overview What is a Usage Scenario? Using Usage Scenarios to Design the NSDSS Usage Scenario #1: Lake Allocation Permitting Is the Usage Scenario right? Building System Requirements

What is a Usage Scenario? Flow chart of multi-participant process Not a software algorithm – a “people algorithm” Created before software is considered Each usage scenario is focused on a real-world process with specific needs for decision support. Multiple Usage Scenarios are supported by the system – many with overlapping requirements. Goal is to define a sufficient number of usage scenarios to fully define the requirements for the system.

What does a Usage Scenario Look Like?

Actions

What does a Usage Scenario Look Like? Grouped Actions (Meta-boxes)

What does a Usage Scenario Look Like? Decisions

What does a Usage Scenario Look Like? Documents

What does a Usage Scenario Look Like? Actors (color-coding: blue = O&G Company, orange = State of AK)

What does a Usage Scenario Look Like? Show thumbnail of US#1 Explain Key – ie. Meta-boxes, processes, documents, etc. Desired Technology Platform

NSDSS Development Timeline Stakeholder collaboration throughout Outcomes of this workshop drive rapid prototype development of next 12 months

Using Usage Scenarios to Design the NSDSS 4 Usage Scenarios identified thus far: –US#1 – Lake Allocation Permitting –US#2 – Ice Road Planning & Permitting –US#3 – Infrastructure Planning (Project Level) –US#4 – Support for NSB Comprehensive Planning Stakeholder participation is crucial to identifying and developing Usage Scenarios to make NSDSS as useful as possible. This list can change if the stakeholders want it to.

Usage Scenario #1: Lake Allocation Permitting Fresh water withdrawals on North Slope require permits from State (and sometimes BLM) Permits written to ensure safe levels of withdrawal from each permitted lake Lake locations and permitted withdrawals are necessary inputs to ice road planning Role of NSDSS –Streamline existing permitting process –Facilitate water balance analysis –Enable long-term planning

Let’s look at the flow chart… Usage Scenario #1: Lake Allocation Permitting

NSDSS TOOL DEMONSTRATION

Is the Usage Scenario right? Are the meta-boxes correct? Do we need more/fewer/editing? Inspect each meta-box individually Completeness Checklist:  Appropriate stakeholders included  Communication between stakeholders  Document production  Technology elements

Building System Requirements Functional Requirements What the software does… Non-Functional Requirements How the software behaves… Institutional Requirements Who uses and maintains the software…

Usage Scenario #1: Requirements & Refinement Functional: Present Maps of North Slope Landscape (Vector and Raster Data) Present Geo-referenced Time Series Provide ability to peruse data Provide an ability to compare existing data with template Provide an ability to enter templates for MPR analysis, WB analysis, Permit application, MPR study reports, WB study reports, permit document Provide an ability to auto-populate analyses and reports according to templates Publish MPR plan and report, WB plan and report, Permit application, permit document

Usage Scenario #1: Requirements & Refinement Functional (continued): Assimilate Collected Data for MPR Study MPR Analysis: Calculate Vol, Ice Vol, Fraction of Under-Ice Volume, Determine if Fish are Sensitive, Ice-chip analysis, snow harvest analysis, allocation computation. Assimilate Collected Data for Additional Study Water Budget Analysis: Process Input time series for water budget analysis, Assign processed time series to terms in water budget equation, calculate water budget, assess safe yield. Bind and Package Permit Application Submit permit application

Usage Scenario #1: Requirements & Refinement Non-Functional: Security/Accessibility User Friendliness, Ergonomics Performance Open-ness, API, Modularity Technology (db formats, web/desktop, use of existing data systems) Standardization – compatibility/integration with other systems Scalability

Usage Scenario #1: Requirements & Refinement Institutional: Users and Roles Maintenance and Updates Funding (esp. after DOE grant ends) Process Changes (Mechanisms for Proposals and Decisions) Peer Review of Data and Models

Usage Scenario Working Groups