Attachment 3 - PWS TO1 - CAVI Support for Web Data Write Access.docx

PERFORMANCE WORK STATEMENT (PWS)

Task Order: CAVI Support for Web Data Write Access

Contract Number: W912HQ-21-D-000X Task Order: 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 support for Web Data Write Access to Corps Water Management System (CWMS) databases via the Control and Visualization Interface (CAVI) used in the HEC Real Time Simulation (HEC-RTS) software and CWMS. 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 CWMS 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 58 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.

CWMS is the Army Information System (AIS) that supports and enhances the decision-making process for the USACE water management mission. USACE is responsible for round-the-clock monitoring and operation of approximately 600 reservoir, lock and dam, and other water control projects. This responsibility also expands, during flood control operations, to approximately 120 additional Section 7 (Non-USACE) projects.

CWMS provides critical information for making decisions that are fundamental in achieving the full range of benefits of the authorized purposes of our projects. CWMS integrates real-time data acquisition, database storage, flow forecasting of watershed runoff, reservoir operation decision support, river profile computation, inundated area determination, consequence analysis, and information dissemination into a comprehensive software package. CWMS and associated software underpin the USACE Water Management Enterprise System (WMES) by acquiring, processing, and reporting the hydrometeorological data required to manage Corps water resources projects under routine and emergency conditions. CWMS incorporates state-of-the-art modeling techniques such as spatially distributed rainfall-runoff flow forecasting, rule-based reservoir systems operation, steady and unsteady-flow water surface profile analysis, 2-D flow analysis, event-by-event flow impact for damage, population, life-loss, and structures. For example, in addition to determining reservoir operations, current and forecasted river water surface elevation/profiles and inundated flood area information can be utilized for flood fight decisions, flood evacuation warnings, and transportation interruption alerts. Additionally, GIS capability provides inundated areas impacted along with specific parcel and structure information if available. CWMS can also be used to estimate potential life-loss due to given flooding scenarios.

1.3 Objectives:

The contractor is to create and modify software code for new capabilities, enhancements and modifications within CWMS and HEC-RTS, as described in the PWS. These tasks support modernization of CWMS connectivity across clients, servers, and databases and is necessary for CWMS to function in the Cloud using a web based approach to push and pull data to and from CWMS databases. The work adds options for reading and writing to the CWMS database using web services instead of an Oracle connection. The primary goals of the additional data access are to provide flexibility and improve performance when CWMS users work from home, and to support migration of CWMS software to cloud environments.

Foundational data objects were previously established in CWMS applications to support loading data from a CWMS database via the CWMS RESTFul API for Data Retrieval (CWMS RADAR) web service. Those foundational elements were designed with the intention of this subsequent effort to allow posting data to a CWMS database via RADAR. Separate ongoing work is extending the RADAR webservice to support storage of data, and associated authentication requirements to be implemented by CAVI and other applications. These improvements must be in accordance with Application Security and Development STIG and the Application Server Security STIG, and also documented in the eMASS Risk Management Framework (RMF) for compliance with AIS requirements for "Authority To Operate" (ATO).

Subsequent tasks in this PWS extend the designs to support other write access by Post process, CWMSVue, Data Validation Editor, scripting (jython) API, and server-side DataExchange. A pair of tasks direct specific review of the implementation once subjected to field conditions, and reflection about potential alternative approaches and new technologies. Other tasks add new capability to the CWMSVue application to easily copy data from HEC-DSS files to a CWMS database, as a priority requirement expressed as part of community feedback during the last CWMS User Representative Group meeting. Yet another task details standard tests to develop. The final task provides follow-up support resources to accommodate agile software development to leverage opportunities revealed by concurrent activities, and to address uncertainties and ongoing changes to the Corps network, cloud environments, and security policies. The work performed under this task order represents the single biggest modernization step toward CWMS 4.0, and serves as the keystone of CWMS functionality in cloud environments.

1.4 Scope: Services to be performed include:

· Source code developed submitted to HEC BitBucket repository

· Development of test procedures and datasets and summary of test results

· Documentation

· Meetings

· STIG Reviews

· DevOps Coordination

· Minor Modifications or Enhancements

· Performing code review.

Services to be performed are defined in section 5 (Information and Requirements Applicable throughout this PWS) and in the task descriptions.

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.

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 the contractor assures 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 Single Source Fixed-Price Contract.

1.6.6 Security Requirements: The contractor and all sub-contractors employees will be issued a CAC for work under this task order that requires Remote access, via logon, to a DoD network using DoD- approved remote access procedures. At the discretion of the sponsoring activity, an interim CAC may be issued based on a favorable review of the FBI fingerprint check and a successfully scheduled NACI at the Office of Personnel Management.

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 contractor employees with access to a government information system must be registered in the Army Training Certification Tracking System (ATCTS) at commencement of services, and must successfully complete the DOD Information Assurance Awareness prior to access to the information systems and then annually thereafter in accordance with personnel security standards listed in AR 25-2 (Information Assurance), an appropriate background investigation will be conducted prior to accessing the government information systems.

All contractor employees, to include subcontractor employees, requiring access to Army installations, facilities, controlled access areas, or require network access, shall complete AT Level I awareness training within 30 calendar days after contract start date or effective date of incorporation of this requirement into the contract, whichever is applicable. Upon request, the contractor shall submit certificates of completion for each affected contractor employee 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 by all employees and subcontractor personnel. AT Level I awareness training is available at the following website: http://jko.jten.mil/courses/atl1/launch.html; or it can be provided by the RA ATO in presentation form which will be documented via memorandum

The contractor and all associated sub-contractors shall receive a brief/training (provided by the RA) on the local suspicious activity reporting program. This locally developed training will be used to inform employees of the types of behavior to watch for and instruct employees to report suspicious activity to the project manager, security representative or law enforcement entity. This training shall be completed within 30 calendar days of contract award and within 30 calendar days of new employees commencing performance with the results reported to the COR NLT 5 calendar days after the completion of the training.

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.

All contractor employees and associated sub-contractor employees must complete the DoD IA awareness training before issuance of network access and annually thereafter. All contractor employees working IA/IT functions must comply with DoD and Army training requirements in DoDD 8570.01, DoD 8570.01-M and AR 25-2 within six months of employment."

All contractor employees supporting IA/IT functions shall be appropriately certified upon contract IAW DoD 8570.01-M, DFARS 252.239-7001 and AR 25-2. The baseline certification as stipulated in DoD 570.01-M must be completed upon contract award.

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: The contractor is responsible for ensuring all employees possessing a CAC maintain current certificates of required DoD trainings mandated for CAC holders.

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/Junior Software Analysts/Programmers, Senior/Junior Hydrologic Engineer, Senior/Junior Software Q/A Engineer and 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 the following Security Technical Implementation Guidelines (STIG):

· Application Security and Development

· Application Server Security Requirements Guide

· Tomcat Application Server Expertise must include RMF-based STIG compliance and review, Annual Security State Testing, Software Threat Modeling, System Security Engineering, and Software Configuration Management. The contractor shall also have familiarity with the configuration and software code languages used within each of these. The contractor’s staff of IT security professionals, engineers, and computer programmers should have a minimum of two 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 Perforce and/or Git, typical branching strategies, and software package building frameworks

2) Software design and development;

3) Client-Server software design and development, subject to widely varying bandwidth and latency conditions;

4) Java programming language and Oracle database programming environment;

5) Application of the Java Native Interface to libraries using FORTRAN, C, and other languages;

6) Capability with HEC-DSS functionality and associated API;

7) Familiarity with CWMS field office server platforms, back-end data processing, and troubleshooting techniques;

8) Hydrologic modeling, especially the use of HEC-MetVue, HEC-HMS, HEC-ResSim, HEC-FIA, and HEC-RAS to support water management operations;

9) Design and implementation of plug-ins for CAVI, HEC-WAT, and HEC-DSSVue;

10) Familiarity with Jython Scripting API used by HEC-ResSim, CAVI, HEC-DSSVue, and ad hoc user programs;

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

12) Familiarity with the CWMS Database schema and related applications, including: Web-based data entry, automated data acquisition and data validation, data dissemination for internal and public uses, and data exchange between the database and other programs (in particular the CWMS suite of modeling software)

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 proposed and accepted in the negotiation 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: HEC will provide licenses and accounts to its Jira issue management as needed. 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.

3.4 Standards: (For DevNet/Github projects) Each individual project will contain a standard set of files, like CONTRIBUTING.md, README.md, that include expected standards for submittal. Recommendations for changes to the standards are gladly accepted and will be reviewed through the pull-request process.

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 maintain its own licenses for Oracle and JOOQ software for purposes of contractor’s code development, testing, and software support.

PART 5

SPECIFIC TASKS

5. Specific Tasks:

Information and Requirements Applicable throughout this PWS Several existing CWMS applications must be improved to implement the CWMS RADAR Client API (see reference https://github.com/HydrologicEngineeringCenter/cwms-radar-client). The entry point to the API is in the controllers package located at: https://github.com/HydrologicEngineeringCenter/cwms-radar-client/tree/main/cwms-radar-client/src/main/java/mil/army/usace/hec/cwms/radar/client/controllers.

Also note these relevant public Technical Resources:

· https://github.com/USACE/cwms-radar-api/

· https://www.hec.usace.army.mil/xmlSchema/cwms/ Copies of code or access to private repositories hec-cwms-data-access and cwms_aaa will be provided as needed on request.

The CWMS AAA (Authentication, Authorization, Audit) service resides in a Tomcat instance with SSL Mutual Authentication Active. The primary end points are:

· CWMSlogin/login

· Which returns the last login date, username, and a JSESSIONIDSSO cookie.

· At this time the JSESSIONIDSSO cookie is the required token.

· Client application that have already presented the DoD Terms of Use banner may pass the query parameter "dod_agree=y" to bypass the login redirect.

· CWMSLogin/logout

· Which will destroy CWMS in database session key information as well as flush Tomcat of the previously acquired session.

· By default given a RADAR Url of

· https://<host>/<district>-data/

· the login service will be found at

· https://<host>/CWMSLogin

· If the service does not exist the instance of RADAR does not support writes at this time. This should not totally fail the "login" sequence but should be prominently indicate that the source is read-only.

· Future work

· An end point to login and receive a JWT will be created at some point. However at this time only the JSESSIONIDSSO is required to be implemented and will not be removed in future development. This JWT would be passed to the RADAR service as a Bearer token in an Authorization header.

The RADAR based authentication will co-exist with existing RMI and login-server based mechanisms supported in the client applications. It may be necessary to re-authenticate when invoking a different database access method.

Implementations under this PWS will support the ability to write data to a single CWMS database via RADAR, consistent with the exiting 1:1 relationship of a CWMS watershed to a server. However, software design choices should anticipate future requirements for the ability to write results to multiple CWMS databases via RADAR wherever practical. At minimum, the source code must be annotated to identify issues that will need to addressed in the future to support writing to more than one database.

On the server side, this new task order will build on the foundational objects developed under previous tasks. Authentication tokens, be they a JWT or simple system JSESSIONID cookie, for write actions must be based on an approved source of authentication. At this time that is the CWMS "AAA" library ("Authenticate-Authorize-Audit") which will be hosted in the same Tomcat instance but a different context and the CWBI Token system. Clients should be flexible in which form is used.

Functional requirements for all work under this PWS include:

· robust client error feedback, so that end users are able to recognize the nature of the problem

· support for Versioned Time Series and Local Regular Time Series, in addition to traditional CWMS database timeseries

· logging performance metrics and fatal errors for purposes of client troubleshooting, and for future reporting to a central enterprise management dashboard Error handling in the client applications and underlying framework objects described in the tasks must provide helpful information and distinguish problems arising from the following:

1. Inability to contact the server (such as malformed URL, server not responding)

2. Version incompatibility (this RADAR data structure is not compatible, this RADAR API version does not support some query)

3. Authentication failed (insufficient privileges, invalid credentials, unrecognized user)

4. Data unavailability (pathname does not exist, or it does and just no data for that time) Presentation of the error information for each client application such as logging, interactive prompts, and CAVI message pane will follow existing mechanisms for reporting database connection issues.

Whenever applicable, updates to source code and build scripts must also include necessary updates to for existing automated testing processes to proceed successfully. For example, new arguments in a function call might require updates to a related unit test, or a change in dependencies could require updates to a Docker container. This requirement applies to existing tests that require only minor updates for compatibility with the new improvements. The support task can be used for contractor assistance where existing tests must be substantially transformed.

Most of the subsequent task descriptions require the Contractor to implement at least one automated test (unit or scripted) on HEC infrastructure to ensure that functionality is verified when CWMS, HEC-RTS, CWMSVue, or related builds occur. The Contractor must consult with HEC about proposed tests, and these requirements are deliberately flexible. Some elemental functionality is best tested immediately as Java classes are compiled, while it is better to test more integrated functionality in a later stage of building the application, in order to verify that different pieces interact properly. It is important for DevOps to both expand the amount of test coverage over the functionality, and to automate the tests as much as practical. Requiring at least one automated test while coding the new features establishes a framework which can be expanded during parallel or subsequent work.

Some of this effort requires collaboration and coordination with HEC staff performing concurrent work regarding RADAR or applications or data-related objects in the underlying software. Some work under these tasks requires the contractor to consult with HEC regarding certain design choices. This consultation, collaboration, and coordination must occur as part the ordinary course of software development for HEC. In situations where Contractor efforts are required outside the tasks explicitly delineated in this scope, the contractor will be directed as described in the “support” tasks.

For reference relevant to the following task descriptions, the figure below renders the UML objects involved in the CAVI ability to extract and post via the RADAR web service (from https://bitbucket.hecdev.net/projects/CWMS/repos/hec-cwms-data-access). The CAVI is the central application of CWMS, and its "extract-post" functionality is representative of extract-transform-load operations in other CWMS applications.

Task 1 – Extend RadarClient and CwmsDbRadar API to Support Write. The cwms-radar-client library and CwmsDbRadar API currently support retrieving the catalog and data regarding CWMS time series data, and must be extended to also store timeseries data and timeseries groups. Similarly, the cwms-radar-client and CwmsDbRadar API must also support storing location, location levels, and location group data to the CWMS database, in addition to the existing read methods. Paired data retrieval and storage must also be supported via a Java implementation of CWMS rating API.

Authentication for RADAR is provided by external services that provide tokens of some type. Either server SESSION ID (CWMS AAA) or JWT (CWBI Tokn application). The client system should sufficiently abstract this from the user such that they only need to know a RADAR service URL. Tokens may be short or long lived and users should be prompted as appropriate to refresh credentials. User tokens should be stored in appropriate locations for day-to-day storage and retrieval, such as a users' AppData directory or another Operating System defined place. During reconnect for any reason (user switching databases, network outage, etc) it is reasonable to first reuse existing stored credentials to provide a better user interface. Credentials may have a life up to 1 week, but should exist no longer.

Authentication may also be automated to rely on stored credentials in the case of scripts and non-interactive processes. Automated clients should fail cleanly, with a clear message about expired or invalid credentials, and fully exit when authentication fails, in order to avoid an accumulation of hung processes.

Contractor must propose "unit" tests to accompany the source code improvements to verify functionality when builds occur. The tests should cover key interactions among components and dependencies, consistent with existing test coverage in the codebase, as seen in https://bitbucket.hecdev.net/projects/CWMS/repos/hec-cwms-data-access/browse/hec-db-integration-testing.

There are design choices to make regarding authentication implementation that must take computational environments into consideration, i.e. standard USACE Windows desktop environments, legacy hardware (Solaris T7), and the Civil Works Business Intelligence (CWBI) cloud. STIGS and agency interpretations of security risks continue to evolve. The CWMS and WMES applications are themselves undergoing other concurrent modernization activities. These considerations may impose constraints on design choices, or burden them with unacceptable impacts on workflow and usability. Consequently, the Contractor will prepare a preliminary design and describe its planned implementation in a meeting with USACE subject matter experts, which will be arranged by HEC staff. Since at this time it is impossible for anyone to decide the "right path" the Contractor must start down those that exist and will suggest modifications to existing RadarClient, CwmsDbRadar API, CWMS_AAA, and CWBI Tokn and login system that simplify or enhance the design, such as RADAR improvements, more effective error handling methods, or additional end point features. Contractor will document feedback and refinements to the design, and conduct a successful demonstration of authentication procedures using a mock version of a CWMS application before proceeding with implementation. All design documentation will be stored with assistance from HEC in the relevant GitHub or HEC BitBucket repositories.

After HEC concurrence on the design choices, the contractor must follow through with implementing the software improvements planned in Task 1. Source code submittals, including internal documentation and unit tests consistent with pre-existing code, will be submitted via pull requests to be accepted by HEC developers. The contractor must also help update and extend build system scripts to reflect changes to dependencies, tests, and artifacts, conforming to previously established conventions for those systems. HEC will provide developers with all necessary accounts and access to code and artifact repositories and systems.

Task 1 Deliverable - The Contractor will provide a rough design outline based on mock application within 30 calendar days of award of this PWS, proposing details of authentication implementation, and any recommended adjustments to existing objects or APIs. Within 90 calendar days of award of the PWS contractor must submit all necessary materials to extend RadarClient and CwmsDbRadar API to support writes to the CWMS database via RADAR. Tickets will be put into HEC issue management system as milestones of the rough outline, and will be approved by HEC. Source code and unit test updates will be submitted through incremental pull-requests to the appropriate GitHub or HEC BitBucket code repositories in alignment with milestones. The increment of each pull-request will be left to the discretion of the contractor but should represent no more than 5-7 days of work and preferably less than 1 day. HEC will review the pull requests for each increment within 3 business days and provide comments about required or suggested alterations or approve and/or merge the PR.

Contractor may submit incremental invoicing at any or all of these progress points:

- 10% initial discussion and design outline with skeletons of units tests

- 30% demonstrate authentication procedures

- 40% location data

- 50% timeseries data

- 60% location groups and timeseries groups

- 80% paired data

- 90% location levels

Period of Performance for Task 1 – 93 Calendar Days from Award of this PWS

Task 2 – Support Posting of CAVI Forecast Results Via RADAR: The contractor must build on the objects and API implemented in Task 1 to support the CAVI storing forecast modeling results from HEC-DSS files to a CWMS database via a RADAR webservice. The implementation should mirror the existing capability to post modeling results from HEC-DSS to a CWMS database via JDBC method as closely as possible. The work requires extensive understanding of the CAVI application and data objects used throughout HEC software, and should be consistent with similar implementations in the existing codebase. This task includes:

· enable post of RADAR data using CaviForecastDx API

· establish RADAR post groups and implement in CAVI post editor

· extend CWMSVue Catalog to support RADAR and implement in CAVI post editor

Contractor must implement "unit" tests to accompany the source code improvements to verify functionality when builds occur. The unit tests should cover key interactions among components and dependencies, consistent with existing test coverage in the codebase. Contractor must also include one automated "integration" test of the new functionality in HEC's TeamCity build system, such as a scripted CAVI run that posts canned results from a prior forecast. HEC will provide access to suitable infrastructure to allow thorough local and automated testing.

Task 2 Deliverable - Within 120 calendar days from acceptance of award of this PWS, the Contractor shall submit updated source code, test procedures, and documentation to the GitHub or BitBucket source code control depots to enable posting CAVI forecast results to a CWMS database via RADAR. HEC staff will have 14 calendar days to review and test the program enhancements, as well as review and comment on the documentation, and request corrections or modifications if needed. The Contractor will have 14 calendar days to address HEC requests or comments and, if revisions are required, the Contractor shall submit updates to the repositories for final acceptance.

Period of Performance for Task 2 – 148 Calendar Days from Award of this PWS

Task 3 – Support Retrieving and Storing from DataValidationEditor via RADAR: The contractor must build on the objects and API implemented in Task 1 to support the CAVI Data Validation Editor (DVE) saving edited data to a CWMS database via a RADAR webservice. The implementation should mirror the existing capability to save edited data from the DVE via JDBC method as closely as possible. The work requires extensive understanding of the CAVI application and data objects used throughout HEC software, and should be consistent with similar implementations in the existing codebase.

Contractor must implement "unit" tests to accompany the source code improvements to verify functionality when builds occur. The unit tests should cover key interactions among components and dependencies, consistent with existing test coverage in the codebase.

Task 3 Deliverable - Within 150 calendar days from acceptance of award of this PWS, the Contractor shall submit updated source code, test procedures, and documentation to the GitHub or BitBucket source code control depots to support retrieving and storing from DataValidationEditor via RADAR. HEC staff will have 14 calendar days to review and test the program enhancements, as well as review and comment on the documentation, and request corrections or modifications if needed. The Contractor will have 14 calendar days to address HEC requests or comments and, if revisions are required, the Contractor shall submit updates to the repositories for final acceptance.

Period of Performance for Task 3 – 178 Calendar Days from Award of this PWS

Task 4 – Support Storing from CWMSVue via RADAR: The contractor must build on the objects and API implemented in Task 1 to support CWMSVue storing data to a CWMS database via a RADAR webservice. The implementation should mirror the existing capability to store data from CWMSVue via JDBC method as closely as possible. The work requires extensive understanding of the CWMSVue application and data objects used throughout HEC software, and should be consistent with similar implementations in the existing codebase. Note that

· Storage must be supported for data from each CWMSVue tab (timeseries, timeseries groups, locations, location levels, location groups, and ratings).

· Storage must be supported for all instances of editing and importing of time series data. This includes math functions, manual time series data entry, CDEC, USGS, CHPS Timeseries Data file, and Excel plugins for importing external data data sources, as well as editing time series data through table view.

· Each instance of CWMSVue need only support one method of database connection at this time, but design choices should anticipate support for writes to multiple databases.

· CwmsCombinedDataManager must support both jdbc and radar connections to db, although in separate instances.

· Functionality should be the same whether CWMSVue runs as a stand-alone application or launched from within the CAVI.

Contractor must implement "unit" tests to accompany the source code improvements to verify functionality when builds occur. The unit tests should cover key interactions among components and dependencies, consistent with existing test coverage in the codebase.

Task 4 Deliverable - Within 180 calendar days from acceptance of award of this PWS, the Contractor shall submit updated source code, test procedures, and documentation to the GitHub or BitBucket source code control depots to support storing from CWMSVue via RADAR. HEC staff will have 14 calendar days to review and test the program enhancements, as well as review and comment on the documentation, and request corrections or modifications if needed. The Contractor will have 14 calendar days to address HEC requests or comments and, if revisions are required, the Contractor shall submit updates to the repositories for final acceptance.

Period of Performance for Task 4 – 204 Calendar Days from Award of this PWS

Task 5 – Support Storing from Scripting API via RADAR: This task enhances the existing Java-based CWMS software to support writing to a CWMS database via the RADAR web service. DBAPI.py should be updated to support “put”, “write”, “close” and related methods for RADAR, similar to that of the existing JDBC access.

Contractor must implement "unit" tests to accompany the source code improvements to verify functionality when builds occur. The unit tests should cover key interactions among components and dependencies, consistent with existing test coverage in the codebase. Contractor must also include one automated "integration" test of the new functionality in HEC's TeamCity build system, such as a script that stores each of the supported data types, then reads them back. HEC will provide access to suitable TeamCity build agent, RADAR web service, and write credentials.

Task 5 Deliverable - Within 210 calendar days from acceptance of award of this PWS, the Contractor shall submit updated source code, test procedures, and documentation to the GitHub or BitBucket source code control depots to support storing from scripting API via RADAR. HEC staff will have 14 calendar days to review and test the program enhancements, as well as review and comment on the documentation, and request corrections or modifications if needed. The Contractor will have 14 calendar days to address HEC requests or comments and, if revisions are required, the Contractor shall submit updates to the repositories for final acceptance.

Period of Performance for Task 5 – 238 Calendar Days…