Upload
duongque
View
216
Download
0
Embed Size (px)
Citation preview
Project Objective
November 2009
Create a statewide Juvenile Migrant database
To establish a prototype juvenile out-migrant data
exchange format for Washington
To share Juvenile out-migrant collection data
Ultimately to share other data streams regionally
(...still to be determined…)
What is the JMX?
A comprehensive database for juvenile migrant data along the lines of SGS
The JMX data exchange template should be thought of as a vehicle to share data in a common format.
JMX is a method to promote communication of primary and derived data.
JMX is a tool to promote collaboration.
JMX is an idea to encourage consistency.
What's in it? Steps to derive juvenile production estimates from primary data
(e) Expanded catch (f) Efficiency strata
Derived data #1
(i) Total production estimate
Derived data #3
(b) Catch data (c) Efficiency trial
Primary data (a) Trapping Period Information
(d) Individual data
(g) Stratified migration estimates
Derived data #2
(h) Extrapolated migration estimates
Our Approach:
Data Template Development
Juvenile out-migrant data collection survey based on HQ data widely circulated
Draft Data Template and Database Schema developed based on outcome of November (2009) Kick-off meeting. Draft data template includes cross walk with existing juvenile databases (RMIS, FPC, ISEMP ATM).
Created a DB schema and data flow configuration document outlining how data might move from field to central DB including sync w NWIFC data
Created a prototype database in use in Olympia and R5 to capture historic data
JMX Data Flow Tribal data sources
WDFW regional data sources
DB
DB
PSP Node
and/ or
Exchange Network
Something
Else
Other
Things
Complete Xfer
JMX
Node
JMX
Node
WEB
UI
WDOE
Node/
WQX
Something
Else Again
JMX Exchange Overview
NWIFC
Tribal Partners
Tribal Juvenile Migrant
Data Management &
Exchange Client
WDFW
Other Partners
Aquascape
Node
Node
WDFW Juvenile Migrant
Data Management
and Reporting System
Server
Exchange Network Node
Exchange Network Client
Datastore
Data Flow
Legend
Train-the-Trainer
JMX Exchange Summary
What will the JMX Exchange allow me to do?:
• Share juvenile migrant data with exchange partners (e.g., Tribes, NWIFC, WDFW, PSP and NMFS)
• Request and receive juvenile migrant data from NWIFC / WDFW supplied by JMX partners (e.g., other Tribes, PSP, WDFW, etc.)
Train-the-Trainer
Juvenile Migrant Client Summary
What will the Juvenile Migrant Client allow me to do?
• Search for, enter and manage juvenile migrant data
• Review raw data for abundance estimation purposes
• Provide juvenile migrant data to partners (e.g., WDFW, NWIFC)
• Request and receive juvenile migrant data from NWIFC / WDFW supplied by JMX partners (e.g., other Tribes, PSP, WDFW, etc.)
• View JMX Client Activity/Transaction Log
• Configure JMX Client
• Receive notification of data Submissions / Receipts / Errors
SCoRE
„CoRE?‟
Barriers Wild Hatchery
SoftData/
TOCAS
LIFT
BroodStock
People
FishBooks
HWS
SGS
SaSI FMPs
FRAM
Age &
Scales
Maint
PSSDB
H2O
Qual
CRC
JMX
FishDist
SSHIAP
Harvest
Actions
$
Wildlife
Fish
Habitat
Exists
In development
Does Not Exist
WGA DSS
Coord Asses
PSP SOS
Key
External Reporting Drivers
Why Brodie ..Why?!?
Greater transparency in the way we do our work
Ability to share data
A home for historical data in an era of Agency
institutional knowledge loss.
A way to document data collection and analysis methods
and protocols
A way to centralize JM data for consistent reporting
(hopefully alleviating some reporting requests placed on
field staff.
A model for regional datasets
Brodie, What else can I do with a node?
WDFW
Node
PSP
BPA Coord
Assessments
WGA
DSS
SoTR
GSRO
SoS
DART
????
General
Overall, The team thought the project ran smoothly.
From conception to implementation, the overall process was probably too long, due to a number of factors.: contractor availability, # of tribal entities, split systems & needs, etc. NWIFC/WDFW thought that accelerating this process next time would be helpful.
Due to the contractor, Windsor, getting involved later in the process, a readiness assessment was needed and some elements of the project were repetitive for the participants who were involved from the onset. NWIFC/WDFW would like to get Windsor involved earlier in the process to prevent repetition of concept communication, however this tradeoff comes at the cost of cost.
Project Exploration, Initiation &
Strategic Planning
This process could have been aided by having more consistent, executive level support/sponsorship from the PSP. Due to changes within the PSP organization, support waned as the strategic plan was being established.
It could have been helpful to get Windsor more involved in this process to help facilitate and coordinate this part of the process. There was a general feeling that if Windsor were involved earlier, the process may have been able to be accelerated.
The high-level strategy established during this process was effective in setting the stage for the project moving forward and was established with the appropriate level of details based on what was known at the time.
Project Scoping/Contracting
Given the planning work NWIFC/WDFW/PSP had performed
to this point, there was a clear vision for the effort and the
scope of the components needed was well defined.
The contracting process seemed to be smooth and without
issue as we were able to reuse many of the standards that
were established in the first WQX contract.
One key missing component in the JMX Exchange is a tool
that PSP (a consumer) can utilize to receive information from
the exchange. The exchange support PSP‟s ability to request
information from the NWIFC/WDFW Nodes, but PSP will
need to utilize the Node Client Lite tool or a Node to make
such a request and this will take some configuration.
Project Planning/Approach/Management
The meeting facilitation techniques utilized during the workshops helped keep the meetings and process clear, organized, focused and effective.
The approach/methodology utilized for project worked well. We discussed the possible use of an Agile development methodology and it was determined that given the number of parties involved and the limited availability of the team members, an Agile methodology may not be a good fit. The team thought the current waterfall approach (for NWIFC client and exchange template/ plugin development) was the best fit for the time being.
The monthly status meetings were scheduled at the appropriate times and keeping these to a ~ one hour meeting was effective.
The team was composed of the appropriate skill sets and representatives to progress the process effectively.
Design Due to the way the process evolved and some of the political issues
encountered, the data entry/management schema was established prior to the exchange/sharing schema. A fairly significant simplification process was required when establishing the unified exchange/sharing schema. In a perfect world, the exchange/sharing schema would be established first or at least in conjunction with the design of the data entry/management schema to prevent rework and divergent designs.
Probably would revisit the dual JMX design and explore some sort of third party hosting to mitigate political/ ownership concerns.
Defining the design of the user-interface using high-level mockups allowed the contractor to understand the desired intent and goals for the system while still allowing the contractor to have some flexibility to implement functionality in the most cost-effective manner. This approach seemed to work well and allowed NWIFC/WDFW to retain some budget at the completion of development which can be used to implement other important functionality.
It would have been helpful to involve non-NWIFC member tribes in the design process to engage them early on and to get their feedback on the design.
Implementation Development and Internal Testing
Everyone seemed happy with the development process.
System Testing
NWIFC would like to have at least three tribes actively involved in the testing effort next time. Three tribes were invited to test, but one tribe was unavailable and another tribe was only partially available to test. Next time, NWIFC thought it would be more effective to physically visit the tribes to confirm the system is correctly installed, walk them through the application functionality and to ensure testing actually occurs. In addition, it may be helpful to schedule (block out) testing time with each test tribe.
It was very helpful for NWIFC and the contactor to have one person (“a gate keeper”) at NWIFC triage, compile and communicate feedback to Windsor on issues that arose during testing. This allowed NWIFC and Windsor to better communicate and track the issues that arose.
WDFW more hierarchical structure naturally lead to a gate keeper model of communication.
Historical Data Compilation
Much woe experienced here
WDFW commenced with concurrent historical data entry, prior
to JMX mothership DB completion -- tighter reign on design
standards for these staging sets would be advisable in future
efforts.
Would‟ve been helpful to have a pre-developed template for
historical data
Some suggested that the loading of historical data should be a
second phase operation of the project after current Data entry
exchange was stabilized.