A02.12 PWS EFMSim Software Maintenance dated 2025.07.09.docx

PERFORMANCE WORK STATEMENT (PWS)

Title: HEC-EFMSim - Maintenance and Support for HEC Java Software related to Ecosystems

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 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 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. Over the last 57 years, 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-EFM Mapper supports spatial analyses commonly done during application of HEC-EFM. 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. The contractor will need to possess the hydrologic engineering and software development knowledge and 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 software maintenance and minor enhancements to HEC java software related to ecosystems code, with a focus on HEC-EFMSim.

1.4 Scope: Services to be performed include:

· 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.

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 an e-mail or Jira Incident Reporting Entry. The contractor is required to log their activities and results under each Jira Incident. The contractor log should include:

1) Government Requestor,

2) Date of service,

3) How advance request was received, Jira or E-mail,

4) Notes from log entry item,

5) Current Status of log entry item,

6) For software bug fixes, provide a description of how the issue was addressed or the bug was fixed, including the tests performed to verify fix, and

7) Hours worked on each log entry item.

Deliverables are further discussed in Technical Exhibit 2.

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.

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 full and open 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 virtual and 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 Mapper, 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 is not required to travel under this contract.

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: Government property is not needed to perform the specific tasks..

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 - Ongoing Modifications and Software Support for HEC Java Software related to Ecosystems with a focus on HEC-EFMSim. The contractor shall provide services to support HEC and perform maintenance and minor modifications of HEC java software related to ecosystems. Details of Task 1 are described below.

This task focuses on known minor enhancements to EFMSim logic and simulation interfaces, including improvements to: 1) computation of attractions in multi-edge-face elements, 2) display of slope dissipation parameter, 3) plotting of stress, 4) reporting of growth actions when multiple growth rules are in effect, 5) labels in day and time interface for road rule, 6) potential instabilities related to hatchery zones, 7) road rule computations, 8) temporal offset when using length-adjusted road mortalities, 9) synchronization between model construct and simulation module when a layout is deleted, 10) masking of long community names in logic interfaces, 11) right-click menu option behaviors in kill/boost rule table, 12) availability of kill/boost rule output as a model variable, 13) availability of spreading rule output as a model variable, 14) persisting of roads editor when creating new study, 15) symbology with road maps, 16) import, management, and deletion of road types, 17) active/inactive status for road snap maps, 18) symbology for new road types, 19) renaming of road types, and 20) computation of attractions, 21) interface consistencies when auto-populating community in new rules, 22) clearing of deleted rules, 23) handling of rule parameters when associated community is changed, 24) more intelligible storage of kill/boost rule season parameters, 25) synchronization between layer symbology in the model construct and simulation module, 26) display of y-axis labels in spreading rule plots, 27) general reworking of scenario builder interface, 28) revisions to sum of rule weights calculation, 29) revisions to attractions for individual rules, 30) revisions to attraction aggregations, 31) density rule attraction included for animations, 32) density total attraction included for animations, 33) instinctual rule strength range adjustment to allow for repulsions, 34) removal of twice-considered season from attractions, and 35) interface appearance consistencies.

Furthermore, additional bugs and needed modifications or enhancements are anticipated during routine testing as the known minor enhancements are implemented. The following deliverables include both known and anticipated items. Anticipated items require issue classification. 40 issue classifications are anticipated. 30 additional bugs (16 minor and 14 routine) are anticipated. 3 additional modifications or enhancements are anticipated. 10 meetings and 3 documentation of software enhancements are anticipated.

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 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.

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 1 Deliverables: The contractor shall not exceed the following representative list of activities.

1) Forty (40) Issue classification

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

Or The contractor 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.

The contractor will submit work logs and invoices to HEC and follow HEC instructions related to invoicing to receive payment for contract work.

PERIOD OF PERFORMANCE FOR TASK 1 IS 720 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/TECHNICAL EXHIBIT LISTING

7. Attachment/Technical Exhibit List:

7.1. Attachment 1/Technical Exhibit 1 – Performance Requirements Summary

7.2. Attachment 2/Technical Exhibit 2 – Deliverables Schedule

TECHNICAL EXHIBIT 1

Performance Requirements Summary The contractor service requirements are summarized into performance objectives that relate directly to mission essential items. The performance threshold briefly describes the minimum acceptable levels of service required for each requirement, e.g. “95% of the time.” These thresholds are critical to mission success.

QUALITY ASSURANCE SURVEILLANCE PLAN (QASP)

Contractor shall comply with assuring the required log contains all required information that has been requested.

a. Timeliness - 100% Completion and submittal of log monthly if work has been requested

b. Quality All work is performed to industry standard 95% of the time

Periodic Surveillance

Inspection by the Government

100% Completion and submittal requested work.

b. Quality All work is performed to industry standard 95% of the time 100% Surveillance

Inspection by the Government

Performance Assessment Plan:

1. Monitoring Performance. During the course of the evaluation period, the COR will track Contractor performance. Interim (mid-term) evaluations may be provided to identify strengths and weaknesses in the Contractor's performance during the period being evaluated. At the end of the period, the COR will assess the Contractor's performance in accordance with the Quality Assurance Surveillance Plan (QASP) and report to the KO.

1. Contractor Self-Assessment. Following each evaluation period, the Contractor may provide a written self-assessment of its performance to the COR to be considered in its report to the KO. The self-assessment may be submitted not later than 5 working days after the end of each evaluation period. The self-evaluation should not exceed 1 page per PRS element. The self-assessment should address both the strengths and weaknesses of the Contractor's performance during the evaluation period. Where deficiencies in performance are noted, the Contractor shall describe the actions planned or taken to correct such deficiencies and avoid their recurrence. The self-assessment itself will NOT be the basis for the payment re-calculation determination.

1. COR Recommendation. The COR will consider all evaluations and any other pertinent information, including Contractor self-assessment, and will prepare a report to the KO with findings and recommendations. The Contractor will be provided a copy of the draft findings and recommendations of the COR and will be afforded the opportunity to identify factual errors. The COR's draft recommendation is not subject to negotiation and the COR will not engage in discussions with the Contractor. Any errors identified by the Contractor will be addressed by the COR in its final report. The Contractor will be provided a copy of the final COR report at the same time the report is submitted to the KO.

1. Payment Determination. The KO may meet with the COR to discuss the COR's report. The KO will make a final determination in writing as to the percentage of work successfully completed, and the resulting payment to be made. A copy of the determination will be provided to the Contractor no later than 45 calendar days after the end of the period being evaluated. All KO decisions regarding payment re-calculations are unilateral decisions made solely at the discretion of the Government.

1. Payment Re-Calculations. Notwithstanding any other clause of this contract, payment re-calculations will be made within the later of 60 days after the end of the evaluation period or 30 days after receipt of an approved invoice.

1. The Quality Assurance Surveillance Plan is one evaluation method the government uses to surveillance performance to determine whether the Contractor meets the standards of performance as defined in the PWS. The absence of a QASP for any contract requirement, however, shall not detract from its enforceability or limit the rights or remedies of the government under any other provision of the contract in determining the quality of the Contractor performance.

FY 2025 HEC-EFMSim maintenance I PWS W QASP

TECHNICAL EXHIBIT 2

DELIVERABLES SCHEDULE

Task 1 deliverables (HEC Java Software related to ecosystems Maintenance)

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 Perforce or Bitbucket Source Control software depots. 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.

Source code, test datasets, and document update to HEC Code depot

Project’s Technical POC, the Project’s Technical Supervisor POC or their designee