| | | | | | | | | |
---|
A | 108125 | 185 | Produce CBFish Status Report | Periodic Status Reports for BPA | The Contractor shall report on the status of milestones and deliverables in Pisces. Reports shall be completed either monthly or quarterly as determined by the BPA COTR. Additionally, when indicating a deliverable milestone as COMPLETE, the contractor shall provide metrics and the final location (latitude and longitude) prior to submitting the report to the BPA COTR.
------------------- | $0 | 0.00% | 04/01/2012 | 10/31/2012 |
B | 108126 | 119 | Manage and Administer Projects | Manage and Administer Project | Submit next year's SOW, Budget, and Property Inventory to the BPA COTR. The SOW should include location, planned metrics, and focal species information for those work elements that require it. If contractor or contractor's organization takes longer than 30 days to sign the contract, the contractor will need to send this funding package to BPA more than 90 days before the end of the current contract.
------------------- | $0 | 0.00% | 02/01/2012 | 10/31/2012 |
C | 108127 | 132 | Produce Progress (Annual) Report | Submit Progress Report for the period Jan-Dec 2012 | The progress report summarizes the project goal, objectives, hypotheses, completed and uncompleted deliverables, problems encountered, lessons learned, and long-term planning. Examples of long-term planning include future improvements, new directions, or level of effort for contract implementation, including any ramping up or ramping down of contract components or of the project as a whole. Date range Mar 2011 to Mar 2011 will be agreed upon by the COTR and the contractor. This may or may not coincide with the contract period. For an ongoing project, a progress report covering a contract period may be submitted under the subsequent contract, if approved by the COTR.
Progress reports must conform to BPA guidelines. See the ''formatting guidelines'' link at the Technical Reports and Publications page: https://www.cbfish.org/Help.mvc/GuidanceDocuments.
If producing a technical report for this contract, a discrete experiment, or a peer-reviewed publication, use work element 183: Produce Journal Article.
------------------- | $0 | 0.00% | 09/15/2012 | 10/31/2012 |
D | 108128 | 160 | Create/Manage/Maintain Database | Manage and Host champmonitoring.org | This work element covers the work Sitka performs to manage and host the CHaMP system database, web application (champmonitoring.org - both PROD and QA environments), and other related components of the system. Sitka is responsible for the physical hosting of the system (a collection of hardware and software) and the day-to-day operations of it.
This work includes applying "patches" or updates to various components of the system such as server operating systems, Microsoft SQL, Microsoft IIS web server, GIS server software, etc. It also includes managing regular on and off-site backups, It also includes real-time monitoring of all primary and secondary systems related to champmonitoring.org. The purpose of this monitoring is to alert the technical team at Sitka as soon as any part of the system shows signs of not responding or of poor performance.
This work covers both the champmonitoring.org web site/application, as well as system interfaces between it and external systems (typically web service interfaces) such as Taurus (cbfish.org), MonitoringMethods.org, and RBT.
------------------- | $12,000 | 3.67% | 01/01/2012 | 10/31/2012 |
E | 108129 | 160 | Create/Manage/Maintain Database | Operational Support | This work element needs to cover various day-to-day or operational data management needs of the CHaMP program. Tasks may include:
* Database Administrator (DBA) work to import / migrate data for the program (e.g. updating design docs, initial frame evaluation, adding sites, etc).
* Custom data migrations or cleanup in resource to issues that arise in the field.
* Custom reports/views that help Crew Leads and Project Managers analyze problems and then work to troubleshoot them.
------------------- | $25,600 | 7.83% | 01/01/2012 | 08/26/2012 |
F | 108130 | 160 | Create/Manage/Maintain Database | Technical Support and Training | Provide technical support to CHaMP core team members and partners including field crews. This function was provided by EDS during 2011, and our plan is to provide the same level of support with the following improvements:
* Better management of equipment and updating of equipment (prevent situation where there are multiple versions of hardware/software being used in the field).
* Provide more regular training/support during field season (requires travel budget).
* Develop webinar / training videos (address issue we saw in 2011 where new crew members who didn't attend CHaMP Camp may not have had adequate training on data management tasks).
------------------- | $20,592 | 6.30% | 01/01/2012 | 08/26/2012 |
G | 108131 | 160 | Create/Manage/Maintain Database | System Improvements | ******* April 2012 amendment (CCR-26887): Expand SOW as follows:
1. App Support - Technical architecture diagram for sending metric file to R-script and return indicator file
2. Watershed Mgmt - Support Visit Management
• Need to address a pain point experienced in 2011 by adding the ability to manage "sets" of visits in order to support easier tracking of progress during the field season, and prioritizing the "processing"
• Improve support for program management by providing more program-wide grids on Program Reports page
3. Metrics Generation
• Update Aux metric engine for 2012 data
• Update Aux and RBT metric engine for 2012 data
• Update RBT metric engine for 2012 data
•
Create new Stick and Tape Metric Enginge
4. Measurement Data Upload
• Add measurement attributes from the new "Stick and Tape" protocol
• Upload and serve a new GDB that stores all site-level topographic data
5. Improve Quality Assurance Workflow
• Display RBT images
•
Display Topo QC summary from post-processing
•
Add QA Status tab to the Watershed Details Page
•
Add a QA status symbol to the Aux measurement navigation on the Watershed Details Page
•
Code new QA tests on derived metrics
•
Add help text to the Aux Measurement tab
***** Original SOW on 1/1/2012
DEPENDENCY ON CHAMP DATA MANAGEMENT ADVISORY GROUP
In order for Sitka to successfully deliver on this work element and provide a great tool for the field crews for 2012, it is critical that we provide avenues for collaboration with a core group of people responsible for helping us determine priorities for the data management system and working through the details of the design of these system improvements. More on this Advisory Group is covered under the Contract Description.
ITEMS TO ADDRESS FOR THE 2012 VERSION OF CHAMPMONITORING.ORG
1. Support multi-years for a program
In various places in the system, need to make sure we fully support viewing/accessing objects (e.g. sites, evaluations, visits, etc.) from multiple years (eg, Site Evaluation, Site Export, etc.)
2. Improve Data Flow / Efficiency (implement the site "data packet" concept)
This is the analog to an item under the Handheld Data Logger deliverable.
* Redesign our Data Upload/Import to consume the new data packet format (rather than CSVs) and to let users edit the “raw” data before the app considers the data clean enough to generate metrics on.
* Get Aux data uploaded, imported, verified, and corrected sooner than last year - need to decouple uploads by data type; support distinct data/work-flow paths for Aux, Photo, and Topo data. In particular, we need to defer uploading of photos until later in field season OR until laptop has a fatter connection.
* Includes investigating other cloud services, or removing cloud entirely from the solution. If we stay with cloud (Egnyte), need to: look into different ways to provision user accounts (e.g. 1 per person rather than 1-2 per watershed)
* Might want to have another level between Watershed and Site for Crews (address issue in 2011 in John Day and UGR whereby ODFW and CRITFC had to download each other's data).
* Building on the editing of measurement data that we supported in 2011, support editing of raw data within the system (not as a CSV file in Excel) within the system as soon as possible.
3. Improve QA functionality
We will work with the Data Management Advisory team to identify ways to improve support for crews conducting QA of site-level measurements and metrics, and watershed-level metrics. Here are the improvements we have already identified from talking with crews and CHaMP team members:
- Improve navigation and reduce error. For example, consider redesigning the Site Details such that there is no Visit dropdown (address Jen O'Neal feedback that its easy to inadvertently edit another crew's data).
- Provide easier ways to view all the data together across the program.
- Support bi-variate charts for Data Quality rather than Data Analysis purposes (the latter should be done in ext. tools)
4. Generate a site map based on 2011 field season data.
The goal is to help crews more efficiently re-locate the site using key coordinates and information from the 2011 site visit. This map should include locations of benchmarks, monuments, control points, and air/water temp loggers (when available). It should also include notes / descriptions entered by crews during the first visit. This site map should compliment the hand-drawn map crews made in the first year.
5. Improve usability and "richness" of existing features
* Improve capability to maintain context (e.g. remember grid filters, but likely need to do other things)
* Page load performance improvements throughout
* Circle back on 2011 "Features" and wrap up loose ends, specifically:
- Improve "metadata" on terms used within the user interface, especially in column headings within grids we need to provide definitions of measurements and metrics, and link to Methods in monitoringmethods.org used to generate those measurements and metrics.
- Viewing a visit's Topo and Photo data and otherwise adding detail to the Site Details page.
- Let users browse a set of sites
- Provide "Crew" based views that only showed the sites / visits for a given Crew
6. Support necessary changes to the River Bathymetry Toolkit (RBT).
This involves collaborating and coordinating with ESSA Technologies, the folks responsible for creating and maintaining the RBT. Sitka worked with ESSA in 2011 to integrate the RBT into champmonitoring.org such that metrics are automatically calculated, but there are still a subset of the sites with TINs that the RBT can not automatically handle and thus need to be manually fixed and then re-run through RBT. We anticipate additional changes to RBT in 2012 that may require updating our interfaces (input and output XML files). We also anticipate the need for RBT to generate additional metrics, which we will then need to ingest into CM and display to the user, make available for download, etc. We will develop a means to access images (JPEGs) of DEMs in order to help users perform QA of their measurements and metrics. Under this component of this work element, we will work with ESSA to engineer a cost effective way to do this. | $116,712 | 35.70% | 01/01/2012 | 08/26/2012 |
H | 108132 | 160 | Create/Manage/Maintain Database | Laptop Data Broker | DEPENDENCY ON CHAMP DATA MANAGEMENT ADVISORY GROUP
In order for Sitka to successfully deliver on this work element and provide a great tool for the field crews for 2012, it is critical that we provide avenues for collaboration with a core group of people responsible for helping us determine priorities for the handheld data logger component of the data management system and working through the details of the improved design(s). More on this Advisory Group is covered under the Contract Description.
We need to build a Windows-based software application that serves as a broker between the champmonitoring.org system and handheld data logger. This is partially necessary because the handheld data logger does not support connecting directly to the internet, and there is a need to mitigate the risk that field crews are using out-of-date data logger software, which will in turn minimize the cost to "fix" or clean up measurement data at the end of the field season. The other benefit of having software that runs on the laptop is that it can improve the automation of moving data to and from the handheld device, which will reduce field crew labor (one less task to accomplish), and greatly reduce opportunity for error (eg dragging the aux data files to the wrong site visit folder. While we're not sure we will need or want to use the Data Broker component for quality control/assurance, having a "beachhead" on the field laptop will make it feasible to support such activities in the future (might be a nice mitigation for the limitation of the small display screen afforded by the handheld device).
FEATURES OF THIS DATA BROKER APPLICATION:
1. Broker data to and from data logger. This will eliminate the need to manually load Site information into the data logger, as well as eliminate the need to drag and drop files from the data logger device to the laptop's file system. Crews will still need to drag and drop photos and topo data to the appropriate site visit folder so that they can be eventually uploaded to champmonitoring.org. This component could assume responsibility for creating visit / DCE folders for Topo and Photo data (instead of having the cloud service replicate the foldering system).
2. Automatically check for updates to the handheld software and/or its supporting data dictionary. If there is an update, the broker app will download it to laptop, and then update the data logger the next time it is connected to the laptop. This should reduce the chance that crews are using old versions of the data logger software.
------------------- | $44,575 | 13.64% | 01/02/2012 | 05/31/2012 |
I | 108133 | 160 | Create/Manage/Maintain Database | Handheld Data Logger Improvements | ******* April 2012 amendment (CCR-26887): Expand SOW as follows:
1. Handheld Data Logger - Add data entry forms to support piloting revised habitat methods that will be implemented in 2013
***** Original SOW on 1/1/2012
CAVEAT: Below is a list of things we anticipate needing to do to improve the handheld data logger application that was built by QCI in 2011. We assume we will be able to improve/enhance (build on top of) the existing data logger software. If, when we get into tackling the items below, we determine that the existing code base can not be easy expanded to accommodate these new needs, we will work with Mike Ward and David Byrnes and QCI to determine an appropriate plan. We don't expect this to happen, but it is important to call out this risk since it would impact our budget for this work element if we are not able to leverage the work to date.
DEPENDENCY ON CHAMP DATA MANAGEMENT ADVISORY GROUP
In order for Sitka to successfully deliver on this work element and provide a great tool for the field crews for 2012, it is critical that we provide avenues for collaboration with a core group of people responsible for helping us determine priorities for the handheld data logger component of the data management system and working through the details of the improved design(s). More on this Advisory Group is covered under the Contract Description.
ITEMS TO ADDRESS FOR THE 2012 VERSION OF THE HANDHELD DATA LOGGER SOFTWARE
1. Research alternatives to the device used in 2011 (Juniper Allegro). This includes a cost/benefit analysis that includes evaluating physical characteristics, operational constraints, and technical capabilities of the various alternatives. If this initial analysis identifies a viable alternative, we will assist a field crew member in conducting field evaluations, ensuring they evaluate the necessary aspects of the alternative in order to support a more informed decision. We recognize that if the decision is made to use a new device, that most likely the CHaMP program will need to have both devices functional in the field for one season in order to mitigate the risk of prematurely swapping out devices. To be clear, this work element does NOT include developing custom software to run on an alternative field data collection device.
2. Update data dictionary and potentially the UI to reflect changes to the protocol. While it is hard to get more specific until we know the total list of changes, here are are few things we know we need to do:
* Update data logger schema to include the version number of the handheld SW (and then on the backend, support multiple versions of the schema). This will make the overall system more resilient should there be multiple versions of the handheld software again.
* Potentially support crews using different drift nets in 2012 (happened in 2011 with CRITFC – Casey Justice)
* UTM coordinates should be managed as a single table (Intention is to address 2011 issue whereby crews only entered one set of coordinates for Bottom of Site, and skipped entering it on other tabs because they used the same physical location for other purposes: Stream Temp gauge location, Monument location, etc.)
3. Improve Quality Control - Enforce data dictionary rules. To reduce errors in the field (avoids errors of omission and reduces labor to fix errors when back in the office, enforce data dictionary rules at time of data entry. For example:
* support the crew specifying if Air Temp and Stream Temp loggers have been installed at a site (and then adapting QC checks accordingly)
* ensure sum of substrate cover = 100
* ensure sum of fish cover > 100
* improve data entry form initialization (e.g. don't default to "0" when "0" is a valid value - caused problems with cobble embeddedness)
* enforce required values (e.g. average bankfull width, width category, site length)
Also, for required fields, let field crew indicate why a required field is missing (e.g. physically impossible OR equipment malfunction).
4. Improve Data Flow / Efficiency (implement the site "data packet" concept). We need to de-couple Aux data from Photo and Topo data, allowing Aux data to flow into backend system sooner so that it can be QC'ed and QA'ed, and allow more timely views into the progress of field crews. For example:
* This item covers the actual work to define and build the "data packet" concept mentioned in the "Support end of day validation..." item. The idea is to avoid creating CSV files which the crew can then edit (without any quality checks or business rules). If the data packet file name is the DCE (SiteID and Date of Visit), it could allow us to get rid of the "Visit" layer in the file system.
* Photos should be managed as a single table, not sprinkled across 5-6 tables. Motive here is to simplify the QC and not throw errors on an Aux table (e.g. Monument) when the photo doesn't exist.
5. Improve QA - Support "end of day" validation or "closeout" of a site. We need to implement an explicit Site Download function that verifies the site *data packet* is complete before the user can physically download it from the handheld to their laptop. Part of this needs to include some QA checks:
* Provide a checklist for the Aux person and another for the Topo crew that walks each through a "survey close-out." Idea is to help less experienced crews avoid common errors. Must be something crew can easily do before leaving site (should take ~ 5 min or less if they don't have errors to fix).
* Verify channel units prior to leaving sites (e.g. display a table and require user (ideally Topo Surveyor) to "sign-off" on it)
* Display a few charts that would help illustrate gross errors (e.g. count of channel units by Tier 2 channel unit types, count of LWD by channel unit)
* Support capturing of the total time required to sample the site (both Aux and Topo data collection activities) to enable downstream analysis
6. Conduct usability / beta testing of new handheld software. We need to validate that changes to handheld don't introduce any usability problems (e.g inefficiencies).
* Evaluate user experience and identify opportunities to improve efficiency
* Update the handheld software to address usability issues
* Conduct usability studies with field crew before field season to validate new design
------------------- | $81,715 | 25.00% | 01/02/2012 | 06/30/2012 |
J | 108793 | 160 | Create/Manage/Maintain Database | Expanded Operational Support (relative to WE E) | ******* New WE in Aug 2012 amendment (CCR-27904) ******
The following tasks will be completed under this work element:
- Additional runs of 2011 surveys through new version of RBT
- Re-load 2011 block allocation data from backups. Upon completion of this task, 2011 metrics and block allocations can be exported from CM.org to be used in calculation of probability weights and 2011 indicators.
- Upload 2012 Macro-invert lab data | $12,000 | 3.67% | 08/27/2012 | 10/31/2012 |
K | 108794 | 160 | Create/Manage/Maintain Database | Expanded Technical Support and Training (relative to WE F) | ******* New WE in Aug 2012 amendment (CCR-27904) ******
The following tasks will be completed under this work element:
- Identify and define updates to metric procedures.
- Additional support for quality assurance and metric generation. | $4,206 | 1.29% | 08/27/2012 | 10/31/2012 |
L | 108795 | 160 | Create/Manage/Maintain Database | Expanded System Improvements (relative to WE G) | ******* New WE in Aug 2012 amendment (CCR-27904) ******
The following tasks will be completed under this work element:
- Script to load solar input measurements from Solemetric Suneye exported files to CM.org
- Support entering air and water temperature logger metadata for rotating panel 1 sites;
- Support storage of air and stream temperature data files
- Provide a minimum of a one-time download/access to all air and water temperature data to CHaMP team by November 1, 2012 even if this access is outside of CM.org
- Modify RBT input file to support change detection analysis schema changes in survey GDB
- Update metric calculations based on 2012 analysis framework discussions (The contracted value for this task is half of what was proposed, to fit within project budget constraints and because not all of this work could occur within the performance period. Additional work on this deliverable should be anticipated for FY13.) | $9,500 | 2.91% | 08/27/2012 | 10/31/2012 |