A02.12 PWS EFM Mapper and Ecological Software Maintenance revised 2023.09.06.docx

PERFORMANCE WORK STATEMENT (PWS)

Requirement Title: EFM Mapper and Maintenance and Support for HEC Java Software related to Ecosystems

Contract Number: TBD

Part 1: General Information

1. GENERAL: This is a non-personnel services contract to provide the United States Army Corps of Engineers (USACE), Institute for Water Resources (IWR), Hydrologic Engineering Center (HEC) with development of a new software tool and maintenance and support for the HEC java software related to ecosystems. The Government shall not exercise any supervision or control over the contract service providers performing the services herein. Such contract service providers shall be accountable solely to the Contractor who, in turn is responsible to the Government.

1.1 Description of Services/Introduction: The contractor shall provide all personnel, equipment, supplies, facilities, transportation, tools, materials, supervision, and other items and non-personal services necessary to perform development, maintenance and support for HEC software as defined in this Performance Work Statement except for those items specified as government furnished property and services. The contractor shall perform to the standards in this contract.

1.2 Background:

The mission of the Institute for Water Resources, Hydrologic Engineering Center (HEC) is to serve as the USACE Center of Expertise in the technical areas of surface and groundwater hydrology, river hydraulics and sediment transport, hydrologic statistics and risk analysis, reservoir system analysis, planning analysis, real-time water control management and a number of other closely associated technical subjects. HEC's primary goal is to support the nation in its water resources management responsibilities by increasing USACE’s technical capability in hydrologic engineering and water resources planning and management. In addition to supporting USACE along with Division and District Offices, HEC provides technical support to the Corps overseas. Additionally, HEC provides services to other Federal, state, local and international agencies engaged in these technical areas.

The primary way HEC accomplishes this mission is by developing state-of-the-art software tools bringing them to state-of-the practice that are reliably used by water resources engineers and planners. Since its inception in 1964, HEC has been developing and integrating software tools that support the water resources computing requirements for Corps field offices, headquarters, laboratories, and other Federal, state and international agencies. The software created by HEC has been developed in many software programing languages. Currently, the majority of the coding is done in the Java programming language, but portions also include Fortran, C/C++ and Visual Basic.NET.

HEC java software related to ecosystems support a diverse set of tasks related to USACE water management, ecosystem restoration, and natural resource management missions. HEC-RPT (Regime Prescription Tool) is used to help groups of scientists, engineers, and water managers access hydrologic data and draft flow recommendations while formulating different ways to manage rivers. HEC-EFM Plotter (Ecosystem Functions Model) facilitates access to analyses of ecosystem restoration alternatives. HEC-EFMSim simulates and tracks the status of natural resources under different environmental and management scenarios.

Performance of the contract must be completed by a firm that has extensive software development skills with an emphasis on civil engineering, including emphasis on environmental and water resources tools and analyses. This skill set needs to include knowledge of water resources engineering in the context of the USACE (United States Army Corps of Engineers) mission requirements for hydrologic simulation, statistical analysis, and 1D and 2D hydraulic simulation, and a high level of knowledge and experience with the software code utilized for this work. The firm’s professional staff of engineers, mathematicians, and computer programmers will need to possess the hydrologic, statistical, and hydraulic modeling and programming skill set needed to support.

All of the HEC java software related to ecosystems provide critical information for making decisions that are fundamental in achieving the full range of benefits of the authorized purposes of Corps projects. HEC java software related to ecosystems incorporate state-of-the-art modeling techniques such as spatially distributed forecasting, rule-based ecosystem dynamics, steady and unsteady-flow water surface profile considerations, 2D ecosystem analysis, and event-based effects on ecological population.

Due to both developmental demands and staff limitations, it occasionally becomes incumbent upon HEC to contract for highly specialized services to assist in software devolvement or refinement of specific software applications. A firm which possesses specialized knowledge where the intersection of hydrologic engineering and software development meet is required; a firm with a level of sophistication required to fully appreciate the interrelated connectivity of the hundreds of thousands lines of code and the inter-relationship of the various software which HEC develops and makes available to others for use.

1.3 Objectives:

For the contractor to provide support to HEC by assisting in activities associated with development of a new tool called EFM Mapper and software maintenance and minor enhancements to existing HEC java software related to ecosystems code.

1.4 Scope:

EFM is an HEC software designed to help study teams determine ecosystem responses to changes in the flow regime of a river or connected wetland. EFM analyses involve: 1) statistical analyses of relationships between hydrology and ecology, 2) hydraulic modeling, and 3) use of Geographic Information Systems (GIS) to display results and other relevant spatial data. Through this process, study teams are able to visualize and define existing ecologic conditions, highlight promising restoration sites, and assess and rank alternatives according to predicted changes in different aspects of the ecosystem.

EFM is applied in concert with two other HEC software tools. EFM Plotter helps users view, navigate, and interpret time series and statistical output generated by EFM (per #1 above). GeoEFM supports spatial analyses commonly done during applications of EFM (per #3 above). EFM Plotter works seamlessly with EFM. As with EFM, EFM Plotter interface labels are available to users for editing. GeoEFM projects are created separately and then synchronized with EFM projects. Use of GeoEFM requires licenses related to proprietary ArcGIS software.

This effort is about creating a new software called EFM Mapper, which is designed to work seamlessly with EFM and assist with management and viewing of spatial data, computation and comparisons of habitat areas, applications of habitat suitability indices, and assessment of habitat functionality.

EFM Mapper is envisioned as a GIS software. Much of the fundamental GIS functionality needed in EFM Mapper (e.g., add layers, view layers, zoom, pan, symbology, etc.) has already been coded for other HEC software. The existing software most relevant to EFM Mapper and its fundamental GIS needs is HEC-EFMSim. EFM Mapper also will leverage HEC-RPT and HEC-EFM Plotter code.

The contractor shall adapt existing HEC ecological software code to create EFM Mapper per the following categories: 1) user interfaces, 2) basic GIS functionality, 3) custom GIS functionality, 4) connections with EFM, and 5) code management and build systems.

In addition, the contractor shall provide services to support HEC with software maintenance tasks, including the following:

· Evaluating and classifying issues within the existing software code.

· Performing bug fixes in code.

· Providing minor modification or enhancements to the code.

· Providing field support activities.

· Supporting HEC by attending and actively participating in meetings.

· Providing supporting documentation.

1.5 Period of Performance:

The period of performance (PoP) for this contract is listed task by task. See Part 5, Specific Tasks, Deliverables and PoP Dates for the actual PoP.

1.6 General Information

1.6.1 Quality Control: The contractor will develop and maintain an effective quality control program to ensure services are performed in accordance with this PWS. The contractor will develop and implement procedures to identify, prevent, and ensure non-recurrence of defective services. The contractor’s quality control program is the means by which they assure themselves that their work complies with the requirement of the contract.

Specifically, the contractor will be responsible for developing and executing a plan for initial testing of all features of EFM Mapper. The contractor shall develop unit tests as appropriate to validate any computational logic (i.e. non-UI code) created as part of each task. In addition, test data will be provided by HEC in support of integration and functional testing. HEC will review builds that wholly complete any of the defined task components or at likely test points within a task component (e.g., completion of one of the custom GIS tools).

1.6.2 Quality Assurance: The government shall evaluate the contractor’s performance under this contract in accordance with the Performance Assessment Plan and Quality Assurance Surveillance Plan, shown in Technical Exhibit 1. This plan is primarily focused on what the Government must do to ensure that the contractor has performed in accordance with the performance standards. It defines how the performance standards will be applied, the frequency of surveillance, and the minimum acceptable defect rate(s).

1.6.3 Recognized Holidays: The contractor is not required to provide performance services on Federal Holidays.

1.6.4 Place of Performance: Most the work to be performed under this contract will be performed at the contractor’s facility. If needed, the contractor can periodically perform work or attend meetings at HEC, Davis, CA

1.6.5 Type of Contract: The government will award a Firm Fixed-Price contract.

1.6.6 Security Requirements: When on-site at HEC the contractor and all associated sub-contractors employees (visitors) shall comply with the standards and procedures for all visitors at the facility. Visitors must sign in upon arrival, showing proper ID and sign out upon departure. All visitors will be escorted while on-site.

The Contractor must pre-screen Candidates using the E-verify Program (http://www.uscis.gov/e-verify) website to meet the established employment eligibility requirements. The Vendor must ensure that the Candidate has two valid forms of Government issued identification prior to enrollment to ensure the correct information is entered into the E-verify system.

All new contractor employees will complete Level I OPSEC Training within 30 calendar days of their reporting for duty. Additionally, all contractor employees must complete annual OPSEC awareness training. The contractor shall submit certificates of completion for each affected contractor and subcontractor employee, to the COR or to the contracting officer (if a COR is not assigned), within 5 calendar days after completion of training. OPSEC awareness training is available at the following websites: https://www.iad.gov/ioss/ or http://www.cdse.edu/catalog/operations-security.html; or it can be provided by the RA OPSEC Officer in presentation form which will be documented via memorandum.

1.6.6.1 Physical Security: The contractor and all associated sub-contractor employees shall comply with all applicable HEC access and local security policies and procedures. The contractor shall be responsible for safeguarding all government equipment, information and property provided for contractor use. If the contractor or sub-contractor is conducting work at HEC, at the close of each work period, government facilities, equipment, and materials shall be secured.

1.6.6.2 Key Control: If the contractor works at HEC and requires a key, the contractor shall establish and implement methods of making sure all keys/key cards issued to the Contractor by the Government are not lost or misplaced and are not used by unauthorized persons. NOTE: All references to keys include key cards. No keys issued to the Contractor by the Government shall be duplicated. The Contractor shall develop procedures covering key control that shall be included in the Quality Control Plan. Such procedures shall include turn-in of any issued keys by personnel who no longer require access to locked areas. The Contractor shall immediately report any occurrences of lost or duplicate keys/key cards to the Contracting Officer (KO).

1.6.6.2.1. In the event keys, other than master keys, are lost or duplicated, the Contractor shall, upon direction of the KO, re-key or replace the affected lock or locks; however, the Government, at its option, may replace the affected lock or locks or perform re-keying. When the replacement of locks or re-keying is performed by the Government, the total cost of re-keying or the replacement of the lock or locks shall be deducted from the monthly payment due the Contractor. In the event a master key is lost or duplicated, all locks and keys for that system shall be replaced by the Government and the total cost deducted from the monthly payment due the Contractor.

1.6.6.2.2. The Contractor shall prohibit the use of Government issued keys/key cards by any persons other than the Contractor’s employees. The Contractor shall prohibit the opening of locked areas by Contractor employees to permit entrance of persons other than Contractor employees engaged in the performance of assigned work in those areas, or personnel authorized entrance by the KO.

1.6.7 Special Qualifications: No special qualifications are necessary.

1.6.8 Post Award Conference/Periodic Progress Meetings: The Contractor agrees to attend any post award conference convened by the contracting activity or contract administration office in accordance with Federal Acquisition Regulation Subpart 42.5. The KO, Contracting Officers Representative (COR), and other Government personnel, as appropriate, may meet periodically with the contractor to review the contractor's performance. At these meetings the KO will apprise the contractor of how the government views the contractor's performance and the contractor will apprise the Government of problems, if any, being experienced. Appropriate action shall be taken to resolve outstanding issues. These meetings shall be at no additional cost to the government.

1.6.9 Contracting Officer Representative (COR): The COR will be identified by separate letter. The COR monitors all technical aspects of the contract and assists in contract administration. The COR is authorized to perform the following functions: assure that the Contractor performs the technical requirements of the contract; perform inspections necessary in connection with contract performance; maintain written and oral communications with the Contractor concerning technical aspects of the contract; issue written interpretations of technical requirements, including Government drawings, designs, specifications; monitor Contractor's performance and notifies both the KO and Contractor of any deficiencies; coordinate availability of government furnished property, and provide site entry of Contractor personnel. A letter of designation issued to the COR, a copy of which is sent to the Contractor, states the responsibilities and limitations of the COR, especially with regard to changes in cost or price, estimates or changes in delivery dates. The COR is not authorized to change any of the terms and conditions of the resulting order.

1.6.10 Key Personnel: The following personnel are considered key personnel by the government: Senior Software Programmers, Professional Engineers with water resources expertise, Mathematicians, as well as the Contractor’s Principle(s). The contractor shall provide a contract manager who shall be responsible for the performance of the work. The name of this person and an alternate who shall act for the contractor when the manager is absent shall be designated in writing to the COR. Qualifications for all key personnel are listed below:

1.6.10.1 Contractor Experience: The contractor must have a skill set that includes knowledge of water resources engineering in the context of the USACE mission requirements for hydrologic simulation. The contractor must have a high level of knowledge and experience with HEC java software related to ecosystems, including HEC-RPT, HEC-EFM Plotter, and HEC-EFMSim. The contractor shall also have familiarity with the software code languages used within each of these models. The contractor’s staff of professional engineers, mathematicians, and computer programmers should have a minimum of five years of experience in their respective discipline and possess the programming skillset needed to understand the engineering principles behind the code as well as provide software code fixes and enhancements. Collectively, key personnel should also have appropriate abilities in the following areas:

1) Experience with software source code management using Bitbucket, typical branching strategies, and software package building frameworks;

2) Object oriented software design and development;

3) Java programming language;

4) Familiarity with visualization of statistical ecosystem modeling results, especially display of HEC-EFM results within HEC-EFM Plotter;

5) Spatial ecosystem modeling, including movement associate with ecological communities;

6) Use of spatial and temporal data sets for ecosystem modeling, including GeoTIFF, float, HDF, shape, and flat files;

7) Familiarity with HEC java software related to ecosystems schema and related applications, including: GIS projection management, model parameter storage, data exchange between the database and other programs, and use of data stored in HEC-DSS for river and ecosystem management applications of HEC-RPT;

8) Software QA/QC processes, testing, framework design, and documentation;

9) Experience with Jira for software development issue tracking.

1.6.10.2 Identification of Contractor Employees: All contract personnel attending meetings, answering Government telephones, and working in other situations where their contractor status is not obvious to third parties are required to identify themselves as such to avoid creating an impression in the minds of members of the public that they are Government officials.

1.6.11 Contractor Travel: The contractor may be required to travel to attend and participate in meetings. The contractor will estimate the travel costs before the trip is authorized. Included in that estimate the contractor will state who they propose attend. Travel and proposed contractor attendee(s) estimates will be submitted in writing (email is acceptable) by the contractor to the technical POC and COR for written approval/acceptance. All travel reimbursement will be paid per the Joint Travel Regulations. Actual receipts must be submitted with the invoice.

1.6.12 Other Direct Costs: No other direct costs are anticipated within the PWS.

1.6.13 Data Rights: The Government has unlimited rights to all documents/material and source code produced under this contract. All documents and materials, to include the source codes of any software, produced under this contract shall be Government owned and are the property of the Government with all rights and privileges of ownership/copyright belonging exclusively to the Government. These documents and materials may not be used or sold by the contractor without written permission from the KO. All materials supplied to the Government shall be the sole property of the Government and may not be used for any other purpose. This right does not abrogate any other Government rights.

1.6.14 Organizational Conflict of Interest: Contractor and subcontractor personnel performing work under this contract may receive, have access to or participate in the development of proprietary or source selection information (e.g., cost or pricing information, budget information or analyses, specifications or work statements, etc.) or perform evaluation services which may create a current or subsequent Organizational Conflict of Interests (OCI) as defined in FAR Subpart 9.5. The Contractor shall notify the KO immediately whenever it becomes aware that such access or participation may result in any actual or potential OCI and shall promptly submit a plan to the KO to avoid or mitigate any such OCI. The Contractor’s mitigation plan will be determined to be acceptable solely at the discretion of the KO and in the event the KO unilaterally determines that any such OCI cannot be satisfactorily avoided or mitigated, the KO may affect other remedies as he or she deems necessary, including prohibiting the Contractor from participation in subsequent contracted requirements which may be affected by the OCI.

PART 2

DEFINITIONS & ACRONYMS

2. DEFINITIONS AND ACRONYMS:

2.1. DEFINITIONS: Terms used within the PWS that required definition are listed below.

2.1.1. CONTRACTOR. A supplier or vendor awarded a contract to provide specific supplies or service to the government. The term used in this contract refers to the prime.

2.1.2. CONTRACTING OFFICER. A person with authority to enter into, administer, and or terminate contracts, and make related determinations and findings on behalf of the government. Note: The only individual who can legally bind the government.

2.1.3. CONTRACTING OFFICER'S REPRESENTATIVE (COR). An employee of the U.S. Government appointed by the KO to administer the contract. Such appointment shall be in writing and shall state the scope of authority and limitations. This individual has authority to provide technical direction to the Contractor as long as that direction is within the scope of the contract, does not constitute a change, and has no funding implications. This individual does NOT have authority to change the terms and conditions of the contract.

2.1.4. DEFECTIVE SERVICE. A service output that does not meet the standard of performance associated with the Performance Work Statement.

2.1.5. DELIVERABLE. Anything that can be physically delivered, but may include non-manufactured things such as meeting minutes or reports.

2.1.6. KEY PERSONNEL. Contractor personnel that are evaluated in a source selection process and that may be required to be used in the performance of a contract by the Key Personnel listed in the PWS. When key personnel are used as an evaluation factor in best value procurement, an offer can be rejected if it does not have a firm commitment from the persons that are listed in the proposal.

2.1.7. PHYSICAL SECURITY. Actions that prevent the loss or damage of Government property.

2.1.8. QUALITY ASSURANCE. The government procedures to verify that services being performed by the Contractor are performed according to acceptable standards.

2.1.9. QUALITY ASSURANCE Surveillance Plan (QASP). An organized written document specifying the surveillance methodology to be used for surveillance of contractor performance.

2.1.10. QUALITY CONTROL. All necessary measures taken by the Contractor to assure that the quality of an end product or service shall meet contract requirements.

2.1.11. SUBCONTRACTOR. One that enters into a contract with a prime contractor. The Government does not have privity of contract with the subcontractor.

2.1.12. WORK DAY. The number of hours per day the Contractor provides services in accordance with the contract.

2.1.12. WORK WEEK. Monday through Friday, unless specified otherwise.

2.2. ACRONYMS:

PART 3

GOVERNMENT FURNISHED PROPERTY, EQUIPMENT, AND SERVICES

3. GOVERNMENT FURNISHED ITEMS AND SERVICES:

3.1 Facilities: If the contractor requires access to HEC facilities, the Government will provide the necessary workspace for contractor staff, including desk space (when available), telephones, computers and other items necessary to maintain an office environment.

3.2 Equipment: If government property is needed to perform the specific tasks, the Government will provide computers or any other necessary equipment required to support the work outlined in the PWS.

3.3 Materials: The Government will provide any necessary software code required to perform tasks described in the PWS.

PART 4

CONTRACTOR FURNISHED ITEMS AND SERVICES

4. CONTRACTOR FURNISHED ITEMS AND RESPONSIBILITIES:

4.1 General: The Contractor shall furnish all supplies, equipment, facilities and services required to perform work under this contract that are not listed under Section 3 of this PWS.

4.2. Equipment: The Contractor shall purchase Bitbucket, Jira and TeamCity license(s) by the time of award.

PART 5

SPECIFIC TASKS

5. Specific Tasks:

Task 1 - Adapt existing code to support creation of a new software called EFM Mapper. This task is about creating a new software called EFM Mapper, which is designed to work seamlessly with EFM and assist with management and viewing of spatial data, computation and comparisons of habitat areas, applications of habitat suitability indices, and assessment of habitat functionality.

The contractor shall conform to the following code management and build system requirements when completing tasks:

· EFM Mapper code will be stored in HEC BitBucket.

· Builds will be made via TeamCity and deployed to Nexus for all builds.

· EFM Mapper names in the build system will be identical to those for EFM Plotter, except that “Mapper” will replace “Plotter”.

· All work progress and issues will be tracked in Jira.

Task 1.1 Create User Interfaces. The primary user interface of EFM Mapper will consist of a title bar, menu bar, map window, layer selection tree, and message center (Figure 1). The EFMSim layout interface will be adapted for use in EFM Mapper with the following adjustments:

a. Title bar reads “EFMProjectName – HEC-EFM Mapper #.##.###” (version number)

b. Menu bar:

i. “File” menu options reduced to “Save Project” | “Exit”

ii. “Settings” menu options reduced to “Map Properties”, “Project Properties” | “Aerial Imagery”, and “Display Coordinate System” | “Languages” (added, as in EFM Plotter)

iii. “View” menu options reduced to “IDE Log”

iv. “Windows” menu reduced to “Layouts”, which is renamed to “Maps” with submenus for “Layer Selection”, “Map Windows” | “All”

v. “Help” menu with option “About”

vi. “Edit” and “Tools” menus are removed

c. Map window(s):

i. Title bar reads “Name - Map”

ii. Tool buttons limited to pointer, zoom, pan, ruler, and pointer identify

iii. Map window menu bar:

1. “Layouts” renamed “Maps” with options reduced to “New”, “Open”, Save As”, “Rename”, “Delete” | “New Map Window” (renamed from “New Layout Window”. Maps named by user; map names must be unique to project

2. “Maps” renamed “Layers” with option for “Add Map Layer”

3. Add menu option for “Tools” with options for “Habitat Suitability” with submenu options for “Manage HSIs…” and “Apply HSIs…”, “Raster Calculations” with a submenu option for “Value range…”, and “Habitat Areas” with options for “Manage Tables…” and “Generate Tables…”

4. “Diagnostics” and “Elements” menus are removed

d. Layer Selection tree(s):

i. Title bar reads “Name - Layers”

ii. Each map has an associated layer selection tree (i.e., Name - Map | Name - Layers)

iii. Each instance shows all layers associated with project

iv. Layers can be added to any map window via the “Layers” menu or via application of “Tools” that generate new layers

v. New layers are added at top of layers stack for each map

vi. Any map window can be used to change symbology. Symbology options same as in EFMSim. Symbology changes are made globally to all maps

vii. Layer order and selected/deselected status is applied and saved locally, per map

viii. When a map is opened, its layer selection tree is opened too

ix. Right-click menu options for “Layers” are “Expand” and “Collapse”, as in EFMSim

x. Right-click menu options for individual layers are “Expand”, “Collapse” | 4 standard “Move” options | “Change Label…”, “Attributes Table…” (for vectors) | 3 standard “Scale” options | “Set Layer Source…” | “Remove Map” renamed to “Remove Layer” | “Properties”

e. Message Center:

i. “Message” table same as EFMSim

ii. “IDE Log” opens to message center

Figure 1. Primary interface and components of EFM Mapper, to be adapted from EFMSim.

Task 1.1 Deliverables: The contractor will provide draft source code and documentation of testing to HEC staff within 75 days of award. All source code will be delivered to BitBucket. HEC staff will review the draft source code within 10 days and provide review comments. Contractor will address review comments noted by HEC staff and submit revised source code for final acceptance within 10 days of receiving comments from HEC staff.

Task 1.2. Create Basic GIS Functionality. Much of the basic GIS functionality needed in EFM Mapper to display results and other spatial data (e.g., add layers, view layers, zoom, pan, symbology, etc.) has already been coded for EFMSim. Specific data formats supported and functionalities to be adapted via this contract are detailed below.

a. New EFM Mapper projects ask user to declare unit and coordinate systems as in EFMSim

b. Add/remove raster datasets. Supported raster formats are floats and GeoTIFFs as in EFMSim

c. Add/remove vector datasets. Supported vector formats include shape files as in EFMSim

d. Missing data sources are repaired one at a time; repair triggered by opening map with missing data as in EFMSim

e. Pointer, zoom, pan, ruler, and pointer identify tools

i. Pointer is mainly used to illustrate position; pointer holds its arrow cursor appearance outside of map window as in EFMSim

ii. Zoom decreases scale (zooms in) with a double left click or a left click hold and drag and release; zoom increases scale (zooms out) with a single right click; zoom uses the magnifying glass cursor appearance; all of these features as in EFMSim

iii. Pan relocates the map image without changing scale; pan uses the hand cursor appearance; all of these features as in EFMSim

iv. Ruler measures distance (per a series of left clicks) and area (per a series of right clicks) with results communicated via a pop-up window; separate maps have separate pop-up windows; all of these features as in EFMSim

v. Pointer identify tool opens a window that reports values of layers per any map click point. Window offers dropdown list that allows users to specify which layer(s) to query with options for Visible, Top, All, and individual layers of the maps. User setting sticks until changed. Visible is default (Figure 2).

vi. Symbology is managed by right clicking the layer to manage and selecting the “Properties” menu option. Symbology options for rasters and vectors will be included as in EFMSim.

1. “Red - Green” will be added to the set of existing raster color ramps

2. Attribute tables for vectors will be editable upon user command, including adding and populating new attributes via manual entry or pasting

Figure 2. Interface showing output from pointer identify tool.

Task 1.2 Deliverables: The contractor will provide draft source code and documentation of testing to HEC staff within 125 days of award. All source code will be delivered to BitBucket. HEC staff will review the draft source code within 10 days and provide review comments. Contractor will address review comments noted by HEC staff and submit revised source code for final acceptance within 10 days of receiving comments from HEC staff.

Task 1.3. Create Custom GIS Functionality. In addition to basic GIS functionality, EFM applications use IS to apply spatial tools that are commonly used in ecosystem restoration and management projects. Specific tools to be developed are management and application of habitat suitability indices (HSIs), raster calculations, and creation of habitat area tables.

a. Management of HSIs. Selection of the “Tools – Habitat Suitability – Manage HSIs” menu option will open an interface (Figure 3) that allows users to view, add, rename, copy, delete, download to excel, and import from other EFM Mapper projects.

i. View, add, rename, copy, and delete work as in EFMSim for management of rules

ii. HSIs are stored in the “EFMProjectName-HSI.hdf” file

1. A project-specific integer id is assigned to each HSI when created

2. HDF contents include 1) integer id named data tables that contain the corresponding HSI paired data and 2) a table of integer ids and corresponding HSI name strings

3. Renaming HSIs affect name and not integer id

4. Deleted HSIs removes name and integer id – deleted ids are not reused

5. Imported HSIs are comprised of name and data and are assigned new ids

iii. Each HSI, whether added or imported or renamed, must have a unique name

1. Import of HSIs that would have duplicate names fails with message returned to user listing HSIs that could not be imported

iv. Import of HSIs works like import of systems in HEC-RPT, where a source project is opened and the user selects systems to import to the current project (Figure 4)

v. Download to excel creates a spreadsheet with worksheets for each HSI. Worksheet name is HSI name. When HSI name exceeds character limitations for excel, names are truncated and assigned a numerical suffix of “(#)”

b. Application of HSIs. Selection of the “Tools – Habitat Suitability – Apply HSIs” menu option will open an interface that allows users to parameterize and execute an existing jython script. Parameters include input raster name (must be in EFM Mapper project), HSI name (must be in EFM Mapper project), checkbox option to exclude zero suitability areas – default setting is off, output raster name, and output raster location (Figure 5)

c. Raster calculations. Selection of the “Tools – Raster Calculations – Value Range” menu option will open an interface that allows users to parameterize and execute a raster query that reclassifies the raster in accordance with parameters. Parameters include input raster name (must be in EFM Mapper project), value range, output raster name, and output raster location (Figure 6). Values must be numbers; blanks treated as min (left) or max (right)

d. Creation of habitat area tables. Selection of the “Tools – Habitat Areas – Manage Tables…” menu option will open an interface that allows users to construct tables. The interface will allow users to manage tables via commands for add, rename, copy, and delete. The interface also allows users to specify which EFM flow regimes, relationships, and result layers are to be considered (Figure 7)

i. Flow regimes, relationships, and raster layers are selected from lists. Flow regime and relationship lists come from EFM. Raster layers list comes from EFM Mapper.

ii. EFM Mapper needs to store flow regime and relationship selections based on their integer ids from EFM and display corresponding names in tables

iii. Transpose puts flow regimes in rows and relationships in columns – default is off

iv. Right click options for “Add Column”, “Add Row” which add to right or bottom | “Insert Column (left)”, “Insert Row (above)” | “Delete Column”, “Delete Row”

v. Table names must be unique within an EFM Mapper project

e. Generation of habitat tables. Selection of the “Tools – Habitat Areas – Generate Tables…” menu option will open an interface that allows users to generate habitat area tables. The interface allows users to specify which table to generate, the report name and location, and the units, precision, and comparisons to report. A “Use Suitabilities” options is offered. Generated tables can be saved by the user and copied to other software, including excel and word (Figure 8)

i. When the “Apply” button is clicked a table of habitat areas corresponding to the associated raster layers (ie, layers selected in the table construct) is generated

ii. Multiple tables can be generated and are saved per name and location

iii. Users can copy from generated tables

1. Table right click menu options offered for “Select All” (also control A keystroke) and “Copy” (also control C keystroke)

iv. When the “Use Suitabilities” option is on, suitable areas are computed and reported. Suitable areas are the sum of raster cell size multiplied by raster value

Figure 3. Interface for management of HSIs.

Figure 4. Interface for import of HSIs.

Figure 5. Interface for application of HSIs.

Figure 6. Interface for application of raster value ranges.

Figure 7. Interface to construct habitat area tables.

Figure 8. Interface to generate habitat area tables.

Task 1.3 Deliverables: The contractor will provide draft source code and documentation of testing to HEC staff within 225 days of award. All source code will be delivered to BitBucket. HEC staff will review the draft source code within 10 days and provide review comments. Contractor will address review comments noted by HEC staff and submit revised source code for final acceptance within 10 days of receiving comments from HEC staff.

Task 1.4. Create Connections with EFM. EFM and EFM Plotter and now EFM Mapper share information to provide an intuitive user experience. EFM connections with EFM Mapper will be managed the same way as EFM Plotter is managed.

a. As the EFM “Plot” menu supports EFM Plotter (Figure 9), the EFM “Map” menu will allow users to activate, specify location, and manage connections with EFM Mapper

b. The EFM Mapper executable will be named “HEC-EFMMapper.exe”

c. Development versions of EFM Mapper will be portable

d. The formal install location is C:\Program Files (x86)\HEC\HEC-EFM Mapper\1.0\ but the software will be usable from any install location

e. EFM Mapper projects will be saved as “EFMProjectName.map” in the EFM project directory

f. As with EFM and EFM Plotter, interface labels in EFM Mapper will be available to users for editing. Corresponding info will be stored and managed as done for EFM Plotter

Figure 9. EFM “Plot” menus supporting EFM Plotter. A parallel “Map” menu will support EFM Mapper.

Task 1.4 Deliverables: The contractor will provide draft source code and documentation of testing to HEC staff within 275 days of award. All source code will be delivered to BitBucket. HEC staff will review the draft source code within 10 days and provide review comments. Contractor will address review comments noted by HEC staff and submit revised source code for final acceptance within 10 days of receiving comments from HEC staff.

Task 1.5. Documentation. The contractor will prepare draft user guidance for EFM Mapper in Microsoft Word and editable figures in a common format such as Microsoft Powerpoint. User guidance for EFM Mapper will be added to existing user guidance for EFM.

Task 1.5 Deliverables: The contractor will provide draft documentation to HEC staff within 330 days of award. HEC staff will review the draft documentation within 10 days and provide review comments. Contractor will address review comments noted by HEC staff and submit revised documentation for final acceptance within 10 days of receiving comments from HEC staff.

Task 1.6. Meetings. Meetings will be held at various sites, by phone or by webinar. They will be attended by one Senior Software Programmer and one Software Tester associated with the software development. Each meeting is expected to last 2 hours, including preparation and follow-up time. Twenty meetings are anticipated for EFM Mapper development. If travel is involved with the meetings, the contractor will estimate the travel costs prior to authorization of the trip. Included in that estimate the contractor will state who they propose attend. Travel and proposed contractor attendee(s) estimates will be submitted in writing (email is acceptable) by the contractor to the technical POC and COR for written approval/acceptance. All travel reimbursement will be paid per the Joint Travel Regulations. Actual receipts must be submitted with the invoice.

Task 1.6 Deliverables: The contractor will provide draft meeting minutes to HEC staff within 10 days of each meeting. HEC staff will review the draft documentation within 10 days and provide review comments. Contractor will address review comments noted by HEC staff and submit revised meeting minutes for final acceptance within 10 days of receiving comments from HEC staff.

PERIOD OF PERFORMANCE FOR TASK 1 IS 365 DAYS FROM AWARD.

Task 2 - Ongoing Modifications and Software Support for HEC Java Software related to Ecosystems: The contractor shall provide services to support HEC and perform maintenance and minor modifications of HEC java software related to ecosystems. Details of Task 2 are described below.

1. Issue Classification. Issue classification requires the contractor to evaluate an issue and determine if the issue is:

It is expected that a contractor can classify issues within an hour. The contractor must identify the type of issue and have HEC’s approval in writing prior to conducting any work.

2. Bug Fixes in software code. Troubleshooting program behavior; test production sites and then correcting the codebase for the identified errors. Test the bug fix with a variety of data sets to ensure problem is adequately addressed. If applicable, ensure that bug fixes are compatible within the GUI and any changes to the model are displayed correctly. Document how the code was fixed and the testing performed.

3. Field Support Activity. The users of the HEC software will periodically require assistance from the contractor on software set-up and/or usage. This includes proposing and implementing alternative work flows or interim workarounds where bug fixes and software enhancements are deferred to later updates.

4. Minor Modifications or Enhancements. The government will periodically identify functionality gaps in code. The tasks associated with a minor modification will normally require but are not limited to:

Any minor modification or enhancement should be tested with a variety of datasets to ensure it functions appropriately. If applicable, ensure that modifications are compatible within the GUI and any changes to the model are displayed correctly. Document all modifications or enhancements along with test verifications. The effort for the contractor to resolve a minor modification of the codebase is expected not to exceed two days.

5. Meetings. Meetings will be held at various sites, by phone or by webinar. They will be attended by the contractor’s Principal and the one Senior Software Programmer associated with the software development. Each meeting is expected to last four hours. Contractor will take meeting minutes and will provide them to HEC within 10 days of the meeting. If travel is involved with the meetings, the contractor will estimate the travel costs prior to authorization of the trip. Included in that estimate the contractor will state who they propose attend. Travel and proposed contractor attendee(s) estimates will be submitted in writing (email is acceptable) by the contractor to the technical POC and COR for written approval/acceptance. All travel reimbursement will be paid per the Joint Travel Regulations. Actual receipts must be submitted with the invoice.

6. Documentation. Documentation is included with the tasks above but additional documentation requests will be categorized separately.

Work performed under this delivery order must be initiated in advance and in writing at the request of the Project’s Technical POC, the Project’s Technical Supervisor POC, or their designee. Requests must be provided in the form of a Jira Incident Entry. The contractor is required to log their activities and results under each Jira Incident, as well as a log correlating to the requests. The log shall give:

1) Government Requestor,

2) Date of service

3) Notes from log entry item

4) Current Status of log entry item

5) For major bugs fixed, provide a description on how the issue was addressed or the bug fixed, including the tests performed to verify fix.

6) Hours worked on each log entry item

Task 2 Deliverables: The contractor shall not exceed the following representative list of activities.

1) Two hundred One hundred sixty (160) Issue classification

RMA will inform the Technical POC and COR when 80% of the funded task has been utilized. Or.

RMA will inform the Technical POC and COR, when it is anticipated that three months are remaining. This can be estimated by prior usage and communication with the government POC’s. At that time, the government will decide if a modification to this PWS will be put into effect through the Contracting Officer.

Deliverables consist of source code for the government requested minor/routine bug fixes and/or modifications/enhancements, as well as data sets, documents, and instruction materials, as applicable. For all bug fixes (minor, routine and major), deliverables should also include documentation describing the testing performed to verify the bug fix. Testing should be performed on additional datasets to verify that the bug fixes do not introduce addition bugs in other areas of the code.

All delivered source code will be checked-into the appropriate government controlled Bitbucket Source Control software depots. Source code for this software is HEC property and is not to be distributed to other parties or used for other purposes unless as directed by HEC. The contractor will have 5 days to respond to each individual request. The government technical POC will have 5 workdays to review the working program and request corrections or modifications. Contractor will have 5 workdays to address the government technical POC requests or comments.

Each invoice will make reference to a Jira Incident/Ticket Number. Each Jira ticket will have all the information mentioned in the above log.

PERIOD OF PERFORMANCE FOR TASK 2 IS 730 DAYS FROM AWARD.

PART 6

APPLICABLE PUBLICATIONS

6. APPLICABLE PUBLICATIONS (CURRENT EDITIONS)

6.1. The Contractor must abide by all applicable regulations, publications, manuals, and local policies and procedures.

PART 7

ATTACHMENT/…