Atch - DRAFT Performance Work Statement.pdf

PERFORMANCE WORK STATEMENT

FOR SURFACE DEPLOYMENT AND

DISTRIBUTION COMMAND (SDDC)

“Integrated Booking System (IBS)”

29 August 2024

Table of Contents

1.0 BACKGROUND

2.0 SCOPE OF WORK

3.0 GENERAL TASKS

3.1 TASK AREA 1 – CONTRACT LEVEL & PROJECT MANAGEMENT

3.1.1 WEEKLY STATUS REPORT

3.1.2 MONTHLY STATUS REPORT

3.1.3 QUARTERLY PROGRAM MANAGEMENT REVIEWS

3.1.4 EMPLOYMENT STATUS REPORT

3.2 TASK AREA 2 – SUSTAINMENT & MAINTENANCE

3.2.1 CARGO TRANSPORTATION CONTRACT MODIFICATIONS

3.2.2 SOFTWARE SUSTAINMENT & MAINTENANCE

3.2.3 SYSTEM DOCUMENTATION & ARTIFACTS

3.2.4 SYSTEM INTEGRATION

3.2.5 SYSTEM & DATABASE TECHNICAL SUPPORT

3.2.6 SYSTEM & DATABASE ADMINSTRATION

3.2.7 OPERATING, SYSTEMS, RDBMS, & APPLICATION TRAINING

3.2.8 MAINTAIN DISTASTER FAIL-OVER ENVIRONMENT

3.2.9 CONTINGENCY OPERATION SUPPORT

3.2.10 TIER II/III HELP DESK SUPPORT

3.2.11 FISCAM & FIAR SUPPORT

3.3 TASK AREA 3 – ENHANCEMENTS

3.3.1 ENHANCEMENT METHODOLOGIES & PROCESSES

3.3.2 INTEGRATE ENTERPRISE CAPABILITIES

3.4 TASK AREA 4 – CLOUD ENVIRONMENT

3.4.1 MIGRATION TO A COMMERCIAL CLOUD SERVICE PROVIDER

3.4.2 ESTABLISH A CONTRACTOR DEVELOPMENT & TESTING ENVIRONMENT18

3.4.3 MIGRATION OF TESTING AND PRODUCTION TO A GOVERNMENT

APPROVED ENVIRONMENT (OPTIONAL)

3.5 TASK AREA 5 – NEW SOFTWARE DEVELOPMENT / ADVANCED TECHOLOGY

APPLICATION (LH) (OPTIONAL)

3.6 TASK AREA 6 – CONFIGURATION MANAGEMENT

3.6.1 CONFIGURATION MANAGEMENT PLAN

3.6.2 CONFIGURATION CONTROL BOARD

3.6.3 BASE-LINED SOURCE CODE

3.6.4 SOFTWARE RELEASE NOTES

3.6.5 SOURCE CODE MAINTENANCE, CHANGE CONTROL, & CONFIGURATION

CONTROL (VERSIONING)

3.7 TASK AREA 7 – INFORMATION ASSURANCE

3.7.1 WRITING SECURE APPLICATION SOFTWARE

3.7.2 RMF ACCREDIATION

3.7.3 SOFTWARE DEVELOPMENT RMF SUPPORT

3.7.4 DoD PPSM SUPPORT

3.7.5 SOFTWARE CODE SCANS

3.8 TASK AREA 8 – CONTRACT TRANSITION (OPTIONAL)

3.8.1 RAMP UP REQUIREMENTS

3.8.2 EXIT REQUIREMENTS – TRANSITION PLAN

3.8.3 EXIT REQUIREMENTS – TRANSITION PERIOD ACTIVITIES

3.8.4 EXIT REQUIREMENTS – TRANSFER OF MATERIALS PLAN

3.8.5 EXIT REQUIREMENTS – CLOSEOUT REPORT

4.0 GENERAL INFORMATION

4.1 GOVERNMENT FURNISHED EQUIPMENT & SOFTWARE

4.1.1 VIRTUAL DESKTOP INFRASTRUCTURE

4.2 GOVERNMENT FURNISHED INFORMATION

4.3 PLACE OF PERFORMANCE

4.4 PERIOD OF PERFORMANCE

4.5 HOURS OF OPERATION

4.6 INFORMATION ASSURANCE TRAINING

4.7 COOPERATION WITH OTHER CONTRACTORS & GOVERNMENT PERSONNEL

4.8 QUALITY ASSURANCE

4.9 OTHER DIRECT COSTS

4.10 SAFETY

4.11 DELIVERABLES

4.11.1 DELIVERY

4.11.2 INSPECTION & ACCEPTANCE

4.13 SERVICE DELIVERY SUMMARY

5.0 SECURITY (PHYSICAL, PERSONNEL, INFORMATION, ANTITERRORISM/FORCE

PROTECTION, & INDUSTRIAL)

5.1 GENERAL SECURITY INFORMATION

5.2 PERSONNEL CLEARANCE LEVEL & INVESTIGATION REQUIREMENTS

5.2.1 T1 REQUESTS

5.3 CONTRACTOR FACILITY REQUIREMENTS

5.4 CITIZEN & CLEARANCE REQUIREMENTS

5.5 PERSONNEL CLEARANCE VALIDATION

5.6 COMMON ACCESS CARD

5.7 SCOTT AFB/USTRANSCOM/HQ SDDC PHYSICAL ACCESS

5.8 VISITS BY NON-ASSIGNED CONTRACTORS

5.9 VISITS BY PERMANTENTLY ASSIGNED CONTRACTORS

5.10 IN & OUT-PROCESSING

5.11 SECURITY BRIEFING/DEBRIEFING STANDARD FORM 312

5.12 SECURITY TRAINING

5.13 SECURITY PERMISSIONS DOD SYTEMS

5.14 THREAT AWARENESS AND REPORTING

5.15 OPSEC

5.15.1 OPERATIONS SECURITY REQUIREMENTS

5.15.2 COUNTERMEASURES TO UNAUTHORIZED DISCLOSURE OF CRITICAL

INFORMATION

5.16 FPCON IMPACT ON WORK LEVELS (US INSTALLATIONS ONLY)

5.17 SECURITY COMPLIANCE & DEVIATIONS

5.18 SECURITY REGULATION COMPLIANCE

5.19 SECURITY REGULATION GUIDANCE

5.19.1 DEPARTMENT OF DEFENSE (DOD)

5.19.2 ARMY

5.19.3 SDDC

5.19.4 FORMS

6.0 CYBERSECURITY

6.1 HANDLING OF NON-PUBLIC INFORMATION

6.2 PERIODIC GOVERNMENT INSPECTIONS

6.3 USTRANSCOM INCIDENT HANDLING

6.3.1 CYBERSECURITY INCIDENT REPORTING

6.3.2 CYBERSECURITY INCIDENT REPORTING TIMELINES

6.3.3 MANDATORY REPORTING DATA

6.3.4 INCIDENT REPORTING COORDINATION

6.4 INFORMATION SHARING

6.5 CONFIDENTIALITY & NON-ATTRIBUTION STATEMENT

6.6 LAW ENFORCEMENT & COUNTERINTELLIGENCE

6.7 SECURITY TRAINING

6.8 SYSTEM DESIGN & INFORMATION SYSTEM SECURITY ENGINEERING

PRINCIPLES

6.9 DoD ASSESSMENT & AUTHORIZATION

6.10 SOFTWARE ASSURANCE & SECURITY ENGINEERING PRACTICES

6.11 MALICIOUS CODE WARRANTY

6.12 NON-DISCLOSURE OF DATA & INFORMATION

6.13 CYBERSPACE WORKFORCE MANAGEMENT & QUALIFICATIONS

6.13.1 FOUNDATIONAL QUALIFICATION REQUIREMENTS

6.13.2 RESIDENTIAL QUALIFICATION REQUIREMENTS

6.13.3 IT PRIVILEGED USER

6.13.4 USTRANSCOM CYBER WORKFORCE MANAGEMENT AND

QUALIFICATION

7.0 APPENDICES

APPENDIX A – ACROYNMS

APPENDIX B – SYSTEM APPLICATION DESCRIPTIONS & ARCHITECTURE

APPENDIX C – INTERFACE REQUIREMENTS SPECIFICATIONS

APPENDIX D – SOFTWARE DEFECT DEFINITIONS & METRICS

APPENDIX E – DEVELOPMENT ENVIRONMENT SOFTWARE

APPENDIX F – NDA

APPENDIX G – DOD DCWF CODE ASSIGNMENTS

1.0 BACKGROUND

The Integrated Booking System (IBS) is the lead execution system of the Defense Transportation System (DTS) for the global shipment of ocean cargo in support of all peacetime, wartime, contingency, and humanitarian relief operations where Government personnel are involved. IBS provides Surface Deployment and Distribution Command (SDDC) the capability to electronically procure commercial transportation services for the global strategic deployment of Department of Defense (DoD) sponsored cargo. IBS is available to users worldwide, twenty-four hours a day, and seven days a week.

The IBS suite of interoperable systems consists of the applications described in this Performance Work Statement (PWS), Appendix B. These applications and capabilities include but are not limited to providing automated tools to support carrier contract requirement definition, rate and service solicitations and evaluation; vessel schedules; fleet management; book unit and sustainment cargo;

produce shipment documentation; provide cargo offering and status information; and produce order, customs, and manifesting documentation.

The IBS Program Management Office (PMO) resides in the G6 directorate that oversees information technology (IT) systems providing Command, Control, Communications, Information Management, and Intelligence. The G6 directorate oversees Information Management, delivers IT capabilities, and supports SDDC’s mission by designing, developing, implementing, and operating DoD global transportation systems.

2.0 SCOPE OF WORK

This contract shall serve as a vehicle to provide technical engineering services and Software Development Life Cycle (SDLC) management support of the IBS system. IBS consists of separate Development, Non-production, Production and Fail-Over environments currently hosted in the Centralized Enclave (CE) and is in the process of migrating all environments to a Cloud Native computing platform. The contractor shall coordinate with the Government to ensure all activities synchronized and integrated with other SDDC transportation management efforts. The services provided within the scope of this contract follow Covered Defense Information as defined in Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting.

The PWS includes the following task areas, as two primary categories Project Management and Program Support:

• CONTRACT LEVEL & PROJECT MANAGEMENT

• SUSTAINMENT & MAINTENANCE

• ENHANCEMENTS

• CLOUD ENVIRONMENT

• NEW SOFTWARE DEVELOPMENT / ADVANCED TECHOLOGY APPLICATION

(LH) (OPTIONAL)

• CONFIGURATION MANAGEMENT

• INFORMATION ASSURANCE

• CONTRACT TRANSITION (OPTIONAL)

The Contracting Officer (CO) and Contracting Officer Representative/Alternate Contracting Officer Representative (COR/ACOR) are the points of contact regarding decisions on Government requirements and priorities. Unless otherwise specified in this PWS, all days designated are business days.

3.0 GENERAL TASKS

3.1 TASK AREA 1 – CONTRACT LEVEL & PROJECT MANAGEMENT

This task area consists of the functional activities relating to the administration and management of this effort. The contractor shall provide project management and oversight of all projects within the scope of this contract and shall provide and prepare documents such as point papers, briefings, and meeting minutes related to the status and performance of projects. The contractor shall also provide for administrative and technical support to the other tasks in preparation of deliverables and escalate problems or concerns to the CO and COR/ACOR as soon as practicable. The contractor shall assist the Government to ensure cost, schedule, performance, cyber security, and risks are managed for SDDC’s IBS related activities and projects and shall coordinate with the Government to ensure all activities are well synchronized and integrated with SDDC and other transportation organizations management efforts.

3.1.1 WEEKLY STATUS REPORT

The contractor shall provide a Weekly Status Report (WSR), shall outline the status of all new application development, enhancement, and maintenance activities and shall contain issues for discussion during the weekly development meeting attended by the IBS Program Manager (PM), COR/ACOR, and selected contractor personnel. The weekly development meeting is traditionally held on Wednesdays via teleconference; however, the schedule is subject to change. The contractor shall provide the WSR no later than (NLT) the close of business (COB) on the day of the weekly development meeting.

The WSR shall contain the following:

• Development in process

• Financial Improvement and Audit Readiness (FIAR) activities

• Cyber activities

• Releases

• Development planned

• Maintenance in process

• Maintenance planned

• Personnel leave

3.1.2 MONTHLY STATUS REPORT

The contractor shall provide a Monthly Status Report (MSR) NLT the 5th business day of each month.

The MSR shall include an updated Integrated Master Schedule (IMS) which shall include each significant project and all its lower-level tasks and their dependencies with start, finish, and milestone dates. The MSR format shall contain no less than the following information:

• A brief synopsis of the efforts completed, deliverables provided, conferences/training conducted or attended during the reporting period

• Risk assessment and mitigation courses of action

• Proposed activities for the upcoming month, including the IMS

• Financial status of other direct costs (ODC)

• Monthly report of hours/employee for labor hour tasks

• Description of technical approach and management controls to meet cost, schedule, and performance requirements for labor hour tasks.

3.1.3 QUARTERLY PROGRAM MANAGEMENT REVIEWS

The contractor shall schedule and conduct quarterly Program Management Review (PMRs) to begin the first month of each quarter; this meeting typically lasts no more than an hour. The contractor shall present status, progress, recommendations, and concerns in the development of any tasks or documentation described within this PWS. The PMR shall reflect resolution to prior PMR action items, new action items, record discussion activity, decisions made, date, locations, attendees, and a copy of the presentation slides. The contractor shall provide the draft PMR slides to the COR and to the IBS PM NLT two (2) business days prior to the meeting, and minutes of the PMR NLT five (5) business days after the meeting.

3.1.4 EMPLOYMENT STATUS REPORT

The contractor shall ensure all personnel assigned to this contract meet the minimum requirements specified in the contractor’s proposal, in accordance with (IAW) the generic position descriptions provided in the contractor’s proposal. The contractor shall provide an initial Employment Status Report (ESR) (listing/spreadsheet) containing names and labor categories of personnel supporting the tasks identified in the PWS NLT 10 calendar days after contract start date. The contractor shall notify the COR with updates to the ESR NLT one business day after a change in personnel.

3.2 TASK AREA 2 – SUSTAINMENT & MAINTENANCE

IBS shall have 2 environments, IBS, and Legacy IBS. The contractor shall maintain the IBS environment and enhance the IBS applications to include fixing defects, application software, tools, capabilities, servers, interfaces, databases, and related functionality in support of application user communities and the IBS PMO. The contractor shall apply agile development methodologies to provide rapid support and capabilities to the warfighter and humanitarian efforts.

Sustainment and Maintenance tasks may occur after business hours and/or during the weekend. It is expected that all deployment release packages are completely developed and subject matter expert (SME) advisory and troubleshooting support is provided. For deployment releases going into the IBS Production environment, contractor support staff shall be identified and available on-call to resolve issues that may arise.

The contractor shall comply with all architecture standards for database design; perform all development using American National Standards Institute (ANSI) standards, and other DoD standards as directed. The contractor shall ensure that information systems cyber security best practices are employed during all changes to software and the system architecture.

SDDC has prescribed adoption of a common SDDC user experience using the latest version of SnapUI framework built on a custom platform for all programs modernizing their interfaces.

Contractor shall maintain the Legacy IBS environment for 3 to 6 months until decommissioned.

Contractor shall complete payment & modifications to shipment contracts to close out transaction in Legacy IBS. Contractor shall patch environment until decommissioned.

3.2.1 CARGO TRANSPORTATION CONTRACT MODIFICATIONS

The contractor shall design, develop, and implement new software changes in support of United States Transportation Command (USTRANSCOM) and SDDC transportation contracts. USTRANSCOM and SDDC transportation contracts shall include the Universal Services Contract (USC), Guantanamo Bay (GTMO), and Multimodal Contracts. This task area takes priority over all IBS software support efforts unless otherwise advised by the Government.

Rate modification and data changes can occur at any time during execution of the contracts. These shall include new rate types added to the contract, new or changes in dollar amounts of rates already published, new commodity types, new geographical locations, and changes in shipping route indexes.

Changes in reports, formulas and calculations, user operational processes, and access privileges may require the software or data to change.

The products used to determine the requirements for these changes shall include the PWS from USC, GTMO and Multimodal along with input from the operational community in the form of message traffic, telephone conferences, on-site conferences, and other methods. The contractor shall review these products to identify new requirements for software changes. Based on the input described above and coordination with the IBS PM, the contractor shall provide fully functioning tools, modules, and applications available to users via the web greater than 98.5% of the time.

3.2.2 SOFTWARE SUSTAINMENT & MAINTENANCE

The contractor shall implement consistent processes, procedures, and sprint iterations, using agile methodologies.

The contractor shall deliver, for each application, packages consisting of fully functioning tools, modules, and applications available to users via the web greater than 98.5% of the time. Each package shall include a useable product that is abort free with fully documented program source code and complimenting executable code for processing on SDDC hardware. The contractor shall deliver defect free software to the Production environment with no major defects and no more than five (5) medium defects released during a typical twelve (12) month PoP. A major defect is defined as a defect that prevents the accomplishment of an operational or mission essential capability, jeopardizes safety, security, or other requirements designated “critical,” and no work-around solution is known. A medium defect is defined as a defect that adversely affects the accomplishment of an operational or mission essential capability; however, a work-around solution is known. The number of allowed defects shall be adjusted downward proportionately commensurate with PoPs of less than twelve (12) months.

The contractor shall employ the use of Service Oriented Architecture (SOA), Electronic Data Interchange (EDI), Extensible Markup Language (XML), web services (WS), and Application Programming Interfaces (CN)(APIs) as coordinated with the Government, which includes:

• The contractor shall maintain and upgrade all IBS EDI transactions based upon the Defense Transportation Electronic Board (DTEB) Implementation Conventions (IC) and SDDC functional requirements. The contractor shall evaluate EDI changes, ensure IBS business requirements are captured appropriately, risks are identified and addressed, and changes are implemented. The contractor shall work with the IBS Government team and the SDDC EDI Team to ensure DTEB changes meet IBS business rules and practices.

• The contractor shall coordinate with the SDDC EDI Team for updates to existing Electronic

Commerce (EC)/EDI transaction sets, or to create new EDI transaction sets. Currently, IBS utilizes the EDI 300, 301, 303, 304, 315, 824, 858 and 997 transaction sets with IBS, SDDC systems and trading partner(s).

• The contractor shall upgrade IBS EDI data exchanges to a newer X12 EDI DTEB IC Standards version (8010), based upon SDDC migration.

• The contractor shall work with the SDDC EDI Team to test any changes or new transaction sets to ensure the changes meet IBS business rules and practices.

• The contractor shall identify existing sources for new APIs for consumption by existing IBS applications where appropriate.

• The contractor shall implement SOA methodologies and principals and create WS when possible. SOA methodologies and principals, including APIs, shall be developed in coordination with SDDC Enterprise Service Standards (e.g., Enterprise Service Bus (ESB)) and in coordination with the SDDC Middleware Product Suite (MPS) Team. Development using SOA methodologies and principals, in particularly APIs, shall be for increasing software reusability, decreasing redundant features and functionality, and promoting efficiencies. SOA shall be implemented as directed by the Department of the Army.

• The contractor shall maintain, update, or create new EDI crosswalks ensuring changes to X12 are captured.

The contractor shall design, develop, maintain, and implement the capability to allow the exchange of data between different applications and platforms. Integration Capabilities shall include but not be limited to APIs, EDI, Management File Transfer Services (MFTS), and User Defined Files (UDF).

The contractor shall design, develop, implement, maintain, and document APIs in support of consumers of the APIs. Support capabilities shall include the Vessel Schedule, Export Traffic Release Request (ETRR)/Export Traffic Release (ETR), and General Pricing Engine (GPE) APIs. The APIs shall be extensible and flexible enough to be utilized throughout the IBS and SDDC Enterprise. The APIs security mechanism shall be implemented utilizing the current security implementation used by IBS and follow SDDC standards and best practices for APIs security. The contractor shall develop the software using agile development based on iterative and incremental development methodologies and SOA principles.

The contractor shall:

• Support enhancement capabilities to satisfy Government operational or technical requirements.

Support may include creation of supporting documentation to include business case or other analysis to support the need for the change.

• Be responsible for performing system/functional analysis and creating/documenting user stories/acceptance criteria in support of development efforts.

• Documenting all changes in accordance with the IBS Configuration Management (CM) processes.

• Generate a Project Execution Plan.

• Make the IBS source code available to the Government through the SDDC source code repository Version Management tracking tool.

• Review all updates and changes to existing capabilities for acceptance.

• Validate new workflow solutions for acceptance and report findings to the IBS PMO.

• Be required to meet the scheduled Sprint software release dates. Expected delays shall be coordinated with the Government and approved by the PM/COR.

• Coordinate testing requirements with the IBS PMO and/or Enterprise test team to determine functional and regression testing approach. Depending on the scope, complexity and type of development provide release artifacts to assist in performance of Government Acceptance Testing and/or User Acceptance Testing events. These items which may be referred to as other artifacts may include:

• Automated projects which follow instructions to take the application through the workflow to demonstrate the functional updates within the release. This may require one or more projects per release

• API projects which demonstrate the functional changes to web services impacted by the release.

• UDF/EDI files that clearly show the before and after examples of items in a release.

• Updated crosswalk file which was used to during development and to test the UDF/EDI update(s).

3.2.3 SYSTEM DOCUMENTATION & ARTIFACTS

The contractor shall sustain, review, and update system documentation, to include all documentation associated with the application including Architecture and Design, User Guides, Administration, Installation, Crosswalks, and Maintenance Guides NLT (30) calendar days after changes in procedures/processes, system updates or Software Change Request (SCR) implementation.

Documentation shall be reviewed and updated NLT 30 September of each PoP. User and Training Manual updates are required based upon system updates and SCR implementation NLT the fielding of the production change.

3.2.3.1 INTERFACE ARTIFACTS

The contractor shall maintain and update interface artifacts NLT thirty (30) calendar days after changesin procedures/processes, system updates or SCR implementation. Artifacts shall be reviewed and updated NLT 30 September of each PoP. The contractor shall maintain the following interface artifacts:

• Interface Design Description (IDD)

• Interface Requirements Specifications (IRS)

• Interface Requirement Agreement (IRA)

• Interface Control Document (ICD)

• Memorandum of Agreement (MOA)

• Service Level Agreement (SLA)

The contractor shall participate in meetings involving the interface artifacts to resolve issues and share information. Current IBS Interfaces are defined in Appendix C.

3.2.3.2 SYSTEM ADMINSTRATOR MANUAL

The contractor shall maintain and update the System Administrator (SA) Manual NLT thirty (30) calendar days after changes in procedures/processes, system updates or SCR implementation.

Artifacts shall be reviewed and updated NLT 30 September of each PoP. The SA Manual shall address the following:

• Shutdown and restart Aurora databases

• Setup and configuration (e.g., WebLogic, WS02, applications and services)

• Infrastructure diagram and network architecture for IBS

• IBS System startup/shutdown procedures

• User interfaces (UI), ports and protocols

• Linux, Uniplexed Information Computing System (UNIX), Windows and Aurora environments, architecture, and access

• Archive, locations, and management of transaction files

• Daily monitoring, reporting and checklists

• Rate Load operations and procedures

• Installation code, procedures, build and configuration options and associated definitions

• System maintenance, updates, and upgrade policies, operating procedures, error recovery, and schedules

• Database schema, network topology, and flowcharts used to illustrate items such as system designs, data communications, program logic, and the relationships between network nodes

• Instructions for opening/closing and starting/stopping applications, devices, and services under various conditions

• Frequently asked questions and troubleshooting techniques for common issues

• Roles, responsibilities, and contact information for key personnel and support staff

• Failover procedures, logging, and monitoring checklists

• Other miscellaneous and/or relevant items

3.2.3.3 DATABASE ADMINSTRATOR MANUAL

The contractor shall maintain and update the Database Administrator (DBA) Manual NLT thirty (30) calendar days after changes in procedures/processes, system updates or SCR implementation.

Artifacts shall be reviewed and updated NLT 30 September of each PoP. The DBA Manual shall address the following:

• Adding and dropping roles

• Recovering database procedures

• Updating reference files

• Managing cyber security via DBA

• Application and user roles in Aurora environments

• Creating and managing table space, user accounts, and privileges

• Database instances install and configuration procedures

• Rate load operations and procedures

• System maintenance, updates, and upgrade policies, operating procedures, performance and tuning, error recovery, and schedules

• Database schema, network topology, and flowcharts used to illustrate items such as system designs, data communications, program logic, and the relationships between network nodes

• Instructions for opening/closing and starting/stopping applications, devices, logging and monitoring checklists and services under various conditions

3.2.4 SYSTEM INTEGRATION

The contractor shall perform system and data integration tasks necessary to ensure IBS applications meet the technical and performance requirements established by the G6 Ocean Cargo Branch. This includes ensuring accessibility through the current Government single sign on process (i.e., Transportation Enhanced Access Management Service (TEAMS) or other sign on system), and through the .mil or .com networks for all applications in all environments. Additionally, the contractor shall ensure system, software and application integration developed by other vendors is consistent with the SDDC open systems architecture.

3.2.5 SYSTEM & DATABASE TECHNICAL SUPPORT

The contractor shall assist and work in coordination with the CE and Cloud teams when appropriate in maintaining and updating the IBS capabilities, software, and environments to include Development, Non-Prod, Fail-Over, and Production. The contractor shall provide system analysis and engineering support in the maintaining, updating, and documenting the hardware and software associated with IBS Development, Non-Prod, Fail-Over and Production environments. The contractor shall be responsible for end-to-end operations and maintenance services to ensure connectivity of all installed devices related to IBS in the Development environment.

3.2.6 SYSTEM & DATABASE ADMINSTRATION

The contractor shall be responsible for performing or assisting, as required, in SA and DBA on all databases and operating systems in the IBS Development, Non-Prod, Production and Fail-Over Sites in the IBS environments. Administrational tasks shall be performed in the Development, Non-Prod, Production and Fail-Over IBS environments during the PoP. The contractor’s responsibilities shall include the following:

• Production o The IBS contractor shall perform IBS Application maintenance and updating.

o Assist and/or provide technical support to CE with any systems, SA, and/or DBA related issues.

o Assist in satisfy Security Technical Implementation Guide (STIG) requirements and patches.

• Non-Prod o Assist and/or provide technical support to CE with any systems, SA, and/or DBA related issues.

o Assist in satisfy STIG requirements and patches.

• Development o The contractor shall perform IBS operating system and the database maintenance, updating, patching and documentation.

o Satisfy and implementing STIG requirements and patches.

o End to end operations and maintenance.

o Document connectivity of all installed devices.

• Fail-Over o The IBS contractor shall perform IBS application and Database maintenance and updating.

o Assist and/or provide technical support to CE with any systems, SA, and/or DBA related issues.

o Assist in satisfy STIG requirements and patches.

The contractor shall assist with and support operating system and database upgrades as they pertain to the IBS application’s stability and configuration soundness in the Non-Prod, Production and Fail-Over environments by collaborating with members of the CE or cloud managed services team as appropriate.

The contractor shall perform Application software changes to accommodate System and Database software and hardware upgrades and maintenance.

3.2.7 OPERATING, SYSTEMS, RDBMS, & APPLICATION TRAINING

The contractor shall ensure maximum optimization and uptime of the IBS systems, providing fully tested and functioning tools, modules, and applications installed and operating in the current Production environment with no major defects, available to users via the web greater than 98.5% of the time. A major defect is defined as a defect that prevents the accomplishment of an operational or mission essential capability, jeopardizes safety, security, or other requirements designated “critical,” and no work-around solution is known. These tasks include patching, remote and on-site support for all technical aspects associated with IBS for the purpose of tuning/optimizing/maintaining UNIX, Linux, Windows, and the Aurora Relational Database Management System (RDBMS) to ensure that IBS is operationally sustained for high performance levels. The contractor shall update system documentation and interface artifacts NLT 30 calendar days after changes in procedures or processes.

User Manuals, Technical & Procedural Manuals, Instructions, and other documentation shall be updated NLT 30 September of each PoP.

3.2.8 MAINTAIN DISTASTER FAIL-OVER ENVIRONMENT

The contractor shall develop, implement, and complete all required Fail-Over application configurations to ensure the IBS applications are correctly installed and configured to operate at the SDDC Cloud Fail-Over site. In the event of a disaster and to ensure operational consistency, the contractor shall install, configure, and update system and application software and data at the Fail- Over site within one (1) day of availability. Fully functioning tools, modules, and applications available to users via the web greater than 98.5% of the time. Software installed in the Production environment shall not exceed the scheduled release date by more than 10 days unless the delay is coordinated with the Government. The contractor shall deliver abort free software to the Production environment with no major defects and no more than five (5) medium defects released during a typical twelve (12) month PoP. A major defect is defined as a defect that prevents the accomplishment of an operational or mission essential capability, jeopardizes safety, security, or other requirements designated “critical,” and no work-around solution is known. A medium defect is defined as a defect that adversely affects the accomplishment of an operational or mission essential capability; however, a work-around solution is known. The contractor shall validate that data replication is occurring.

Based upon all implemented production software changes, the contractor shall update the Cloud Fail- Over site to reflect those changes NLT one (1) day of production implementation.

The contractor shall provide support to the Government during contingency or emergency operations IAW approved disaster recovery (DR) and contingency operations plans. The contractor shall ensure resources/key personnel are available throughout an emergency IAW the established plan.

3.2.9 CONTINGENCY OPERATION SUPPORT

The contractor shall, upon request, provide up to 24x7 around the clock support to the Government during contingency, emergency, or DR operations as required IAW the approved IBS command contingency operations plan. The contractor shall ensure resources and key personnel are available throughout an emergency IAW the established plan. Personnel may be required on-site or on-call depending on the situation.

3.2.10 TIER II/III HELP DESK SUPPORT

The contractor shall provide Customer Support for all IBS applications and to SDDC’s Systems Response Center (SRC) help desk. The contractor shall provide Tier II/III Help-Desk support allowing customers to escalate problems to the SDDC Headquarter (HQ) location. The IBS Tier II/III Help Desk support shall include the detailed analysis and troubleshooting of problems referred from Tier I. The contractor shall log problem status and resolution information in the SDDC ticketing system (currently ServiceNow) and shall work with SDDC’s Tier I helpdesk personnel to identify trends and areas for improvement. The contractor shall perform a variety of administration Tier II Help Desk support tasks to include answering email from IBS users, and notifying Tier I of application changes, and technical issues. The contractor shall perform Help Desk support during after-duty hours in case of a system outage. Tier I is the consolidated SDDC call center that initiates the initial log and tracks the incident through resolution through the SDDC ticketing system. Tier II shall include having functional knowledge and expertise to answer questions and issues that Tier I was unable answer or resolve. Issues and questions not able to be answered or resolved by Tier I or II shall be elevated to Tier III. Estimated minimum requirement is to solve two hundred (200) Tier II/III helpdesk tickets yearly. The average number of tickets may exceed one thousand (1000) on an annual basis.

3.2.11 FISCAM & FIAR SUPPORT

To ensure the proper operation of IBS, IBS must comply with Federal Information System Controls Audit Manual (FISCAM) guidance for FIAR auditability. FISCAM is consistent with National Institute of Standards and Technology (NIST) guidelines for complying with the Federal Information Security Modernization Act (FISMA) of 2014. This law requires federal agencies to develop, document, and implement agency-wide programs to ensure information security.

The contractor shall assist the Government in ensuring IBS complies with all FISCAM guidelines.

The contractor shall assist the Government in providing IBS program specific input for the development of new auditing documentation and the updating of existing auditing documentation to facilitate IBS auditability IAW current FISCAM guidance. The contractor shall be maintaining and performing logging and monitoring and other FIAR artifacts and reports for supporting FIAR audits.

The contractor shall sustain all IBS applications and databases in all operating environments in compliance with FISCAM Guidance. The contractor shall be required to provide a number of updates to existing documentation NLT 5 business days after Government request. This documentation is required whenever changes are made that may affect the financial audibility of the IBS application.

The contractor shall assist the Government in responding to all auditor inquiries related to IBS FISCAM controls. Auditors shall use FISCAM list of controls to audit IBS. The contractor shall use all applicable tools to develop update and upload IBS supporting artifacts to respond to all auditors’ inquiries in response to any FISCAM findings. The contractor shall also be required to assist the Government to answer, clarify and provide additional artifacts in response to any FISCAM controls findings or auditability requirements.

3.3 TASK AREA 3 – ENHANCEMENTS

The contractor shall design, engineer, and implement secure applications, capabilities, and configurations IAW current DoD guidance for all IBS suites of systems. This list includes software, technologies, processes, applications, capabilities, databases, interfaces, Web Services and API’s.

Enhancements may be capital investments or operational enhancements based on derived requirements.

These capabilities provide automated tools to support carrier contract requirement definition, rate and service solicitations and evaluation; input and update vessel schedules; book cargo; produce shipment documentation; provide cargo offering and status information; produce payment, customs, and manifesting documentation.

SDDC has prescribed adoption of a common SDDC user experience using the SnapUI Framework, built on a custom platform requiring expertise in AngularJS, Foundation, and Sass for all programs modernizing their interfaces.

Automated Information Systems (AIS) require changes as functional requirements and operations change. Therefore, as defined and upon coordination with the COR/ACOR and IBS PMO, the contractor shall develop new solutions for the IBS user community, to include changes for the USC, NSGB and Multi-Modal contracts cited as a separate capital investment Task Area (TA) 2, custom databases, new/updated interfaces, web pages, reports, and applications to streamline or supplement SDDC business processes. The contractor shall attend scheduled and impromptu meetings with the PMO and provide feedback on the status of all ongoing efforts, repairs and changes to capabilities and discuss and validate new workflow solutions based upon PMO and Configuration Control Board (CCB) priorities. SDDC stakeholders, the PMO and the contractor shall review high priority projects via the SCR form, for development evaluation. The IBS program has historically 250 open SCRs.

The contractor shall develop, in coordination with the Government, a Release Schedule and IMS NLT 5 days after request or after meeting. The Release Schedule shall incorporate and account for Government Acceptance Testing (GAT) prior to every Software release. To the maximum extent possible, coordinate with the Enterprise Test Team, keeping informed on testing efforts and using the Automated Test Projects from the master library for all regression testing.

The contractor shall make changes as functional requirements and business operations change, as defined, and directed by the COR/ACOR and IBS PMO, to include software, tools, applications, servers, interfaces and databases for all IBS applications and related functional tools in support of the IBS user community and the IBS PMO. The contractor shall comply with all Architecture Standards for database design; performing all development using ANSI standards, and other DoD standards as required. The contractor shall ensure that information systems security engineering is employed during all changes to the system architecture.

3.3.1 ENHANCEMENT METHODOLOGIES & PROCESSES

The contractor shall enhance existing applications to satisfy IBS program deficiencies which includes enhancement software engineering and changes like custom databases, UI pages, system-to-system interfaces, application web services, APIs, user manuals, SA manuals, training manuals, interface agreements, and applications to streamline SDDC business processes. The documenting of all changes shall be IAW the IBS Configuration Management (CM) processes from PWS TA6.

As part of the enhancement development task for this PWS, the contractor shall generate a Project Execution Plan with the initial plan NLT 30 calendar days after contract award and then updated NLT 7 days from request throughout the contract.

The Project Execution Plan shall also incorporate and account for GAT prior to every sprint software release IAW PWS 3.2.2.

After the establishment of the Project Execution Plan, the contractor shall be required to meet the scheduled sprint software release date, or not exceed the scheduled sprint release date by more than ten (10) business days unless the delay is coordinated with the Government and approved by the COR/ACOR. Those significant delays, delays greater than ten (10) business days, shall be documented and shall include the COR/ACOR signature. Reference Appendix D for software release defects metrics.

3.3.2 INTEGRATE ENTERPRISE CAPABILITIES

The contractor shall design, develop, maintain, and implement the capability to allow the exchange of data between different applications and platforms. Integration Capabilities shall include APIs, EDI, Secure File Transfer Protocol (SFTP), and UDF.

3.4 TASK AREA 4 – CLOUD ENVIRONMENT

3.4.1 MIGRATION TO A COMMERCIAL CLOUD SERVICE PROVIDER

Contractors shall meet DoDD 8140.01 requirements in the contractor development, Testing, Training and Production environments.

USTRANSCOM and SDDC have directed programs to transition applications to a USTRANSCOM Cloud Service Provider (CSP) leveraging cloud managed services and automated pipeline technologies. The desired end-state is to realize Continuous Integration (CI)/Continuous Delivery (CD) as part of DevSecOps per the Command’s Capability Delivery Concept of Operations (ConOps). The contractor shall deliver a development plan and IMS to include Epics NLT 30 days of project award.

As part of the USTRANSCOM migration, IBS shall move to a CSP. The cloud managed service capability shall:

• Enable IBS to tailor the availability and delivery of cloud computing services based on business and technical requirements.

• Unify application and platform which can be measured by the following:

o Consistency – The end result can be reliably achieved through step-by-step standard operating procedures with some foundational knowledge, but minimal system-specific knowledge and the procedures defined therein are reusable from system to system.

o Repeatability – The end result is reproducible in a way that minimizes the probability of error and manual interaction. This includes eliminating steps where practicable and the need for specialized knowledge or training.

o Interchangeability– Technical solutions and operational standards implemented shall enable these objectives so that support is predictable and interchangeable from system to system.

• Support application systems transition to Cloud Service Offering (CSO) that have achieved a DoD Provisional Authorization (PA) at the DoD Cloud Computing Security Requirements Guide (DoD CC SRG) Impact level (IL) 2, 4, 5, and 6.

The following enterprise capabilities are, or shall be provided within the current USTRANSCOM’s CSP environment: Domain Name System (DNS), Microsoft Active Directory, Network Time Protocol (NTP), Simple Mail Transfer Protocol (SMTP), Online Certificate Status Protocol (OCSP), SFTP, Palo Alto Firewall, Splunk, Windows Server Update Services (WSUS), Yellowdog Updater Modified (YUM), Centrify, RedLock, GitLab, Chef, Artifactory, Fortify Static Code Analyzer

(SCA) Software Security Center (SSC), SonarQube, Nessus Security Manager, Eclipse, Maven, and JIRA/Confluence. This list may change as the maturity level of the USTRANSCOM CSP evolves.

The current list of standards (e.g., Operating Systems (OS), Databases (DB), Application Servers, Web Servers, etc.) supported in the USTRANSCOM CSP environment is maintained by the USTRANSCOM. Access to USTRANSCOM’s CSP environment and all the services mentioned above is provided via USTRANSCOM AppStream Cloud Solution. The following are required to access the environment: a common data environment (CDE)/virtual desktop interface (VDI) account, AppStream client installed on the user workstation, and a DOD Common Access Card (CAC) for USTRANSCOM VDI Solution. The contractor shall perform Assess Application Suitability within the USTRANSCOM GovCloud. The contractor shall establish and perform a contractor development & testing non-prod environment for the migration effort and cloud applications shall be maintained fully operational and running parallel to new cloud environment until it is determined by SDDC that they can be decommissioned.

3.4.2 ESTABLISH A CONTRACTOR DEVELOPMENT & TESTING ENVIRONMENT

The contractor shall create a dedicated Amazon Web Service (AWS) organization for all modules managed under Program within Vendor’s AWS Government Cloud (VGC) account. VGC is a secure IL2 environment with restricted access that can build, store, and maintain AWS resources, such as Elastic Compute Cloud, Amazon AWS Relational Database Services, Virtual Private Clouds, Simple Storage Service, and Elastic Kubernetes Service. Where possible the contractor shall use Infrastructure as Code (IaC) to deploy resources to support development to provide a secure, consistent, development, and testing environment that can be logically isolated from other networks.

The contractor shall provide an Integrated Development Environment (IDE), such as Visual Studio, Java etc., for developers to modernize the modules under program. The contractor shall include all required software, artifacts, and tools required to create and store uncompiled and compiled code.

VGC shall comply with SDDC’s 10-day patching policy and be locked down in accordance with Defense Information System Agency (DISA)/FedRAMP IL2 standard. The contractor shall coordinate development efforts with the Government representative, review available CSP and align development efforts with operational requirements of Testing and Production of USTC directed production cloud environment, and leverage technologies that are included in the SDDC DevSecOps pipeline. The IL2 sustainment environment shall be ready for software developers and the contractor shall relocate to the new environment NLT 150 days after contract award.

The contractor shall utilize the SDDC DevSecOps pipeline to escalate code from development to integration, testing, and zero-trust production. The contractor shall adapt to utilizing technologies available to keep the IBS applications modern and capable of CI/CD to the designated zone B (Integration) Government pipeline.

The contractor shall ensure the development environment contains all the necessary developmental products, tools, servers, and databases required to conduct development activities for IBS program that are geared to specific baseline requirements of the end goal. The contractor shall maintain security controls over the data in all environments. Materials required for the development environment shall be similar to current USTC AWS provided environment. HQ SDDC shall provide licenses for ReadyAPI, Toad for Aurora, Fortify etc. The tasks associated with establishing the CDE shall be included as a part of the PWS paragraph 3.5.1 assessment, migration plan, and identified deliverables.

3.4.3 MIGRATION OF TESTING AND PRODUCTION TO A GOVERNMENT

APPROVED ENVIRONMENT (OPTIONAL)

This task area includes providing assessment of the new Environment for IBS Application and Establish Migration Plan for the IBS migration strategy. The contractor shall provide an assessment of the IBS Production, Non-Production (Testing) environments, recommended migration plan for each environment, schedule, and associated costs to assist the Government with determining if additional services are required.

The contractor shall deliver a plan to optimize the applications to perform in a ‘zero-trust’ environment utilizing a DevSecOps pipeline in the cloud either through Refactoring or Redevelopment to the government NLT 30 business days of completing on-boarding scans and receiving results. The plan shall be updated COB Fridays unless it is a holiday then next business day to maintain oversight of progress until completion.

The contractor shall:

• Leverage migration plan as developed in Task 3.4.1

• Develop infrastructure blueprints for creation of all environments to host the application.

Infrastructure blueprints and test scripts shall be provided to PMO NLT 5 business days of Government Acceptance of the migration

• Install application and database per documented instructions/configurations and database dump/image from USTRANSCOM Commercial Cloud. Application blueprints, to include Machine Images (MIs), shall be provided to PMO NLT 5 business days of Government Acceptance Review

• Incorporate approved cloud managed services and capabilities

• Optimize IBS applications to perform in a ‘zero-trust’ environment, to include the DevSecOps pipeline and Cloud Native efficiencies, as applicable

• Modify existing custom scripts for operation in new environment

• Create MIs for instances that make up the application footprint

• Deploy MIs for instances that make up the application footprint

• Establish Resiliency/Failover/Switchover in new environment

• Establish CI/CD pipeline in new environment

• Establish Web Service infrastructure and data exchanges in new environment

• Establish Containerized IBS and incorporate into CI/CD pipeline, if applicable.

• Establish Interface data exchanges Management File Transfer Services (MFTS) in new environment

• Configure UiPath Robotic Process Automations in new environment

• Load a baseline of non-operational data

• Automate the launch of the application in the new environment using DevOps tool chain, if applicable

• Functional Testing:

o Provide access to a fully functional application in new environment for functional/stakeholder validation o Ensure access to the application by authorized users o Demonstrate application functionality o Conduct a review with stakeholders to identify and document issues encountered with the application in the new environment. Determine a resolution date and obtain Government concurrence for open items that shall not be resolved prior to Government Acceptance Review for the Production Environment.

o Track, manage, and resolve incidents that arise during continued functional/stakeholder testing

• Pre-migration:

o Establish, configure, and validate all Testing/Integration/Development/Patch environments in the new environment. Ensure application code changes and infrastructure can be securely promoted from Development to support testing activities. Provide support for a Government Acceptance review of a fully functional Development/Integration/Test/Stage/Pre-Production Test and document the results, to include identified issues and resolutions. Documented issues shall be provided to the Government NLT 2 business days of the Government Acceptance Review. Identified issues shall be resolved (unless agreed to by Government) prior to Government acceptance.

o Establish, configure, and validate Production, to include failover/switchover, environments in new environment. Ensure application code changes and infrastructure can be securely promoted from Testing environments to support system…