2019.12.10 IBS_PWS - DRAFT.pdf

PERFORMANCE WORK STATEMENT

FOR

SURFACE DEPLOYMENT AND DISTRIBUTION COMMAND (SDDC)

INTEGRATED BOOKING SYSTEM (IBS)

Last Revision: 10 December 2019

HTC71120QD008

This page is intentionally left blank.

Table of Contents

SECTION TITLE

1 DESCRIPTION OF SERVICES

2 TASKS

3 DELIVERABLES AND SERVICE DELIVERY SUMMARY

4 CYBER SECURITY

5 GENERAL INFORMATION

6 SECURITY AND REGULATORY GUIDANCE

Appendices

A SYSTEM APPLICATION DESCRIPTIONS AND ARCHITECTURE

B INTERFACE REQUIREMENTS SPECIFICATIONS

C USER AND TRAINING MANUALS

D APPLICABLE DOCUMENTS--FEDERAL LAWS AND STATUTES, DoD

REGULATIONS

E SOFTWARE DEFECT DEFINITIONS AND METRICS

F NONDISCLOUSURE AGREEMENT

G SOFTWARE PRODUCTS

H CONTRACT OBJECTIVE

I PWS ATTACHMENTS

PERFORMANCE WORK STATEMENT (PWS)

INTEGRATED BOOKING SYSTEM (IBS)

VISION: To provide reliable and trusted surface transportation to the Command and to our customers.

MISSION: The Military Surface Deployment and Distribution Command (SDDC) provides global surface deployment and distribution services to meet the nation’s objectives. SDDC is the Army component of the United States Transportation Command (USTRANSCOM). Other Component Commands of USTRANSCOM include the Navy component, Military Sealift Command (MSC), and the Air Force component, Air Mobility Command (AMC). SDDC’s Information Management Directorate (SDDC G6) delivers Information Technology (IT) capabilities that enable global deployment and distribution services.

1 Description of Services

1.1 Background

Data and the information derived from data are key enablers to Department of Defense (DoD) managers and United States (US) war-fighters. Managing the enterprise’s data and promoting its quality across the enterprise ensures the best possible information is available for making informed decisions regarding surface transportation.

Integrating data from a number of disparate sources is required to provide the operators a clear picture of the surface transportation mission – from beginning to end. SDDC books, manifests, moves, tracks, bills, and pays for DoD cargo movement around the globe. SDDC must gather booking data from booking system(s), manifest data from manifesting system(s), and movement data from DoD and carrier systems in order to integrate and share that data across the SDDC enterprise and with other DoD entities. SDDC validates, corrects if needed, integrates, and forwards the data to all SDDC trading partners/systems. SDDC takes the data, applies the appropriate context and business rules, and provides the data to the appropriate user communities, giving them the tools to most efficiently execute DoD’s surface transportation mission.

SDDC’s Operations Directorate, G3, coordinates with other SDDC directorates, higher Commands, DoD shipping agencies, and commercial industry partners to facilitate ocean cargo transportation. The business model for ocean transportation is constantly evolving, and while many efforts have successfully streamlined ocean cargo documentation and tracking, the process still requires new software development and the maintenance and updating of existing business tools, software and practices.

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 SDDC the capability to electronically procure commercial transportation services for the global strategic deployment of 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 PWS, Appendix A. 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 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.

SDDC G6 consists of two (2) Divisions, the Operations Division and the Automated System Division. IBS resides in the Automated System Division, under the Ocean Cargo Branch, which supports the SDDC mission by managing the IBS. SDDC G6 has an Information Assurance (IA) team that will provide certification and accreditation (C&A) support to the IBS applications. The Contractor shall be responsible for providing application-specific documentation and information required for the applications’ C&A packages.

All software developed under this contract is a deliverable to the Government and the Government has unlimited rights to said software (per DFARS 252.227-7014). All technical data provided under this contract is a deliverable to the Government and the Government has unlimited rights to said technical data (per DFARS 252.227-7013). All tasks shall be performed in accordance with (IAW) all regulations and guidelines as shown in Appendix D.

1.2 Scope

The scope of this requirement is to acquire technical engineering services and Software Development Life Cycle (SDLC) management support of the IBS system.

IBS consists of separate development, staging, quality assurance (QA), 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 services provided within the scope of this contract are considered "Operationally Critical Support" (OCS) and Covered Defense Information (CDI) as defined in DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting.

The PWS includes the following task areas in Section 2:

A. Overall Contract and Project Management Task 1: Contract Level and Project Management (FFP) Task 9: Contract Transition and Knowledge Transfer and Transition (OPTIONAL) (FFP)

B. Program Support Task 2: Cargo Transportation Contract Modifications (LH) Task 3: Sustainment and Maintenance (FFP) Task 4: Enhancements (LH) Task 5: Cloud Migration (LH) Task 6: New Software Development /Advanced Technology Application (OPTIONAL) (LH) Task 7: Configuration Management (FFP) Task 8: Information Assurance (IA) (FFP)

1.3 Contract Requirements

The Contractor shall establish and utilize best practices, standards, and repeatable and measureable controls in performing and delivering products associated with existing and future tasks. The Contractor shall, at all times during the Period of Performance (PoP), ensure sufficient personnel are assigned to the effort to fulfill all requirements in this PWS.

1.3.1 Definitions

Contract award is the date on which the Government awards the contract. Contract Initial Operational Capability (IOC) is the first day of contract performance--i.e., the first day of the transition period; IOC ends at the conclusion of the transition period. Contract Full Operational Capability (FOC) is full contract performance, beginning immediately upon completion of transition/spin-up period; FOC is the point when the Contractor assumes full and sole responsibility for all contracted IBS tasks outlined in this PWS.

Unless otherwise specified in this PWS, all days are designated as business days.

The phrases “Government environment(s)” and “IBS environment(s)” or word “environment(s)” may refer to either on premises (On-Prem) or Cloud hosted environments or both, as applicable. The contractor may have to sustain IBS in an On-Prem environment simultaneously with Cloud operations.

1.3.2 Information Sharing

The Government may use and disclose reported information (e.g., information regarding threats, vulnerabilities, incidents, or best practices) that does not include attribution information, at its discretion to assist entities in protecting information or information systems (e.g. threat information products, threat assessment reports);

provided that such use or disclosure is otherwise authorized IAW applicable statutes, regulations, and policies.

1.3.3 Development Methodologies and Processes

The Contractor shall conduct all software development entirely within the consolidated USTRANSCOM/SDDC government environments. The Contractor may access remotely from their facilities through a Government approved Virtual Public Network (VPN) connection, from isolated dedicated development workstations that comply with Government security guidelines.

The Contractor shall be responsible for the successful installation and implementation of government-owned application software onto the government-owned environments. The Government will make use of a centralized software installation/implementation team that will perform code scans and installation of the code into the government-owned environments. For all deliveries, the Contractor shall provide all source code, documentation (including those related to architecture, test design and testing results, and installation procedures), delivered to the government.

The Contractor shall apply agile and iterative development methodologies when practical in execution of the requirements of this PWS.

The Government will perform acceptance testing prior to every sprint Software release. Knowing that each release is unique in its complexity and design, the Enterprise Testing Team and the Contractor’s development team will coordinate what release requirements will be required in preparation for and execution of Government Acceptance Testing (GAT). The PMO, Enterprise Testing Team, and Contractor shall work together create and maintain a single automated test and web service test library. This will require the Enterprise Test Team to have access to the developers’ requirements task management tool.

2 Tasks

2.1 Task 1: Contract Level and Program Management (FFP)

This task consists of the Contractor activities relating to the administration and management of the entire effort.

The Contractor shall provide project management of all projects and tasks within the scope of this contract. The principal project leader shall provide day-to-day oversight of all tasks and projects within the scope of this contract and shall provide or prepare documents such as point papers, briefings, and meeting minutes related to the status and performance of projects. This task shall also provide for administrative/technical support to the other tasks in preparation of deliverables.

The Contractor’s project leader shall escalate problems or concerns to the Contracting Officer (CO) and Contracting Officer Representative (COR) or Alternate Contracting Officer Representative (ACOR) as soon as practicable.

The Contractor shall ensure all personnel assigned to this contract meet the minimum requirements specified in the Contractor’s proposal.

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. The Contractor shall coordinate with the Government to ensure all activities are well synchronized and integrated with SDDC and other transportation organizations management efforts.

2.1.2 Task 1 Subtask 2: Programmatic Documentation

The Contractor shall provide infrequent administrative documentation support as required by writing, reviewing, revising, and delivering program level documents (e.g. reports, briefings, point papers, business case analyses, and additional meeting minutes) on an ad hoc basis.

2.1.3 Task 1 Subtask 3: Weekly Status Meetings and Weekly Status Report (WSR)

The IBS PMO will normally host the Weekly Meeting(s) on Wednesdays via teleconference. The Contractor shall provide a WSR by close of business (COB) every Tuesday or the prior business day when Tuesday falls on a holiday. The WSR shall contain issues for discussion during the weekly development meeting attended by the IBS PM, COR/ACOR, and selected Contractor personnel. The WSR shall outline the status of all new application development, enhancement, and maintenance activities. WSR format should include sections categorized under the headings of: development in process; releases; development planned; maintenance in process; maintenance planned, and personnel leave/travel schedule and shall be presented to the IBS PMO in a mutually agreed to format using Microsoft Office products. Changes to the WSR format or delivery schedule shall be agreed to by the IBS PM or COR/ACOR and the Contractor Program Lead.

Deliverable: WSR weekly by COB on Tuesdays or the prior business day when Tuesday falls on a holiday.

NOTE: The Weekly Meeting(s) will normally be held on Wednesdays via teleconference. The schedule is subject to change with adjustments to WSR deliveries made accordingly.

2.1.4 Task 1 Subtask 4: Monthly Status Report (MSR)

The Contractor shall provide a MSR not later than (NLT) the fifth (5th) calendar day of each month. The MSR shall include an updated Work Breakdown Structure (WBS) which shall include each significant project and all its lower level tasks and their dependences with start, finish and milestone dates. The MSR format shall be agreed upon by the COR/ACOR and the Contractor and 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 WBS

• Financial status (expenses, other direct costs (ODC), travel expenditures)

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

NOTE: The MSR is not required for the month in which a Program Management Review (PMR) (see paragraph 2.1.5) is held, and PMR minutes are provided.

Deliverable: MSR including the WBS NLT the fifth (5th) calendar day of each month.

2.1.5 Task 1 Subtask 5: Quarterly Program Management Review (PMR)

The Contractor shall conduct quarterly PMRs, presenting a briefing to the IBS PM, COR/ACOR. The CO or other Government Contracting personnel may attend if necessary. The PMR shall be scheduled within the first ten (10) days of the month following the end of the preceding quarter, beginning after the first quarter of FOC. The meeting will typically last no more than an hour. The briefing shall include all topics normally discussed in the MSR, highlighting status, progress, recommendations, and concerns in the execution of any tasks described within this PWS or other contractual matters. The quarterly PMRs shall also address and describe evolving technical approaches and management controls employed to meet the cost, schedule, performance, and security requirements inherent to contract execution. PMR documentation shall reflect resolution to prior PMR action items, all new action items, and record discussion activity, decisions made, date, participant and meeting locations (i.e., on-site or phone-in participants; meeting site), attendees, and a copy of the presentation slides used. The Contractor shall provide the draft PMR slides to the COR/ACOR and the IBS Program Manager, NLT two (2) days prior to the meeting. Final PMR slides, to include the milestone schedule, shall be provided at the scheduled meeting. The contractor shall provide PMR minutes, including the final PMR slides, NLT five (5) days after the meeting.

The quarterly PMR documentation shall include an updated WBS which shall include each significant project and all its lower level tasks and their dependences with start, finish and milestone dates. Additional topics for discussion at the PMR include proposed activities not included in the WBS.

Deliverable: Quarterly status meeting NLT ten (10) days after the first business day of the quarter. Draft slides for briefing due two (2) days prior to meeting. Minutes, final slides, and action items NLT five (5) days after the meeting.

2.1.6 Task 1 Subtask 6: Employee Status Report and Organization Structure

The Contractor shall provide an employee status report and organization structure containing names and associated labor categories of personnel supporting the IBS Contract. The report will be provided within thirty

(30) calendar days after contract award and updates to the COR/ACOR NLT five (5) days after change in personnel.

Deliverable: Employee Status Report within ten (10) calendar days after contract award; updates NLT one (1) day after change in personnel.

2.1.7 Task 1 Subtask 7: Trip Reports

Performance under this task order may require Contractor travel within and outside the Contiguous United States (CONUS). The Contractor shall submit a trip report within seven days of return that includes the following details at a minimum: purpose, location, length of trip, individuals contacted and/or trained during trip (including the organization/Command of each individual), synopsis of all discussions, future actions identified, and/or issues of concern arising during trip.

Deliverable: Trip report provided within seven (7) calendar days after return from travel.

2.1.8 Task 1 Subtask 8: Enterprise Contractor Manpower Reporting Application (eCMRA) The contractor shall report ALL contractor labor hours (including subcontractor labor hours and hours incurred for FFP tasks) required for performance of services provided under this contract for Military Surface Deployment and Distribution Command via a secure data collection site. The contractor is required to completely fill in all required data fields using the following web address http://www.ecmra.mil/. Reporting inputs shall be for the labor executed during any period of performance during each Government fiscal year (FY) for which the contract is active. The Government FY starts on 1 October and runs through 30 September of the following calendar year.

While inputs may be reported any time during the FY, all data shall be reported no later than 31 October of each calendar year, beginning with IOC and concluding the year of contract closeout. Contractors may direct questions to the help desk at: http://www.ecmra.mil.

Deliverable: Contractor Management Report NLT COB 31 October each calendar year during the PoP, to include the years in which IOC/Transition and Contract Closeout occur.

2.2 Task 2: Cargo Transportation Contract Modifications (LH, Capital Investment)

This effort is considered a capital investment and takes priority over all IBS software support efforts unless otherwise advised by the Government. The Contractor shall design, develop, and implement new software changes in support of USTRANSCOM and SDDC transportation contracts. USTRANSCOM and SDDC transportation contracts shall include but not be limited to the Universal Services Contract (USC), Guantanamo Bay (GTMO), and Multimodal Contracts).

The products used to determine the requirements for these changes shall include but not be limited to the USC, GTMO and Multimodal PWSs and 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, continuously beginning at Contract FOC. The Contractor shall deliver abort free software to the production environment with no Major defects. There shall be no more than five (5) Medium defects released each contract period.

Rate modification and data changes can occur at any time during execution of the contracts. These shall include but not be limited to 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 Contractor shall document all changes in the SDDC approved change control system; refer to Section 2.7.4, Source Code Maintenance, Change Control, and Configuration Control (Versioning). The Contractor shall update system documentation and interface artifacts based upon system changes within thirty (30) days of changes in procedures/processes--See sections 2.3.2 through 2.3.2.5 for specific artifact and documentation update requirements that also apply to but shall be charged to this task. Documentation and artifacts shall be and reviewed annually NLT 30 September of each year. Artifacts shall include but not be limited to user manuals, technical and procedural manuals, instructions, and other pertinent artifacts.

Deliverable: Fully functioning tools, modules, and applications available to users via the web greater than 98.5% of the time, continuously beginning at Contract FOC. 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.

There shall be no more than five (5) Medium defects as defined in Appendix E released each contract period.

Deliverable: Update system documentation and interface artifacts based upon system changes within thirty (30) days of changes in procedures/processes. Documentation and artifacts shall be and reviewed annually NLT 30 September of each year. See sections 2.3.2 through 2.3.2.5 for specific documentation update requirements that also apply to this task.

2.3 Task 3: Sustainment and Maintenance (FFP)

The contractor shall maintain and enhance the IBS application, 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 whenever practical in order to provide rapid support and capabilities to the war-fighter. The contractor shall continuously maintain and update documentation on the systems architecture and of existing interfaces, data, and software.

Sustainment and Maintenance tasks may occur after 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 ANSI standards, and other DoD standards as directed. The Contractor shall ensure that information systems cyber security is 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 (GOTS) built on a custom platform for all programs modernizing their interfaces.

2.3.1 Task 3 Subtask 1: Software Sustainment and Maintenance

As part of the Software Sustainment and Maintenance Task Area for this PWS, the Contractor shall, when practical, implement the same processes, procedures and sprint iterations, using agile and iterative development methodologies, as defined in Section 1.3.3, Development Methodologies & Processes.

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, continuously beginning at Contract FOC. Each package should include useable product that is abort free with fully documented program source code and complimenting executable code for processing on SDDC hardware. The Contractor shall continually maintain and update corresponding system architecture and interface documentation, data, and software.

The Contractor shall employ the use of Service Oriented Architecture (SOA), Electronic Data Interchange (EDI), Extensible Markup Language (XML), and web services (WS) as coordinated with the Government, which includes but is not limited to:

• 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. 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 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 but not limited to these transaction sets with IBS, SDDC systems and trading partner(s).

• The Contractor shall upgrade IBS EDI data exchanges to a newer X12 EDI DTEB implementation Convention Standards version (7020/7040), 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 WS 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 WS, shall be developed in coordination with SDDC Enterprise Service Standards (e.g., Enterprise Service Bus (ESB)) and in coordination with the SDDC MPS Team. Development using SOA methodologies and principals, in particularly WS, 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 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 WS, EDI, Management File Transfer Services (MFTS), and User Defined Files (UDF).

The Contractor shall design, develop, implement, maintain and document WS in support of consumers of the WS.

Support capabilities shall include but not be limited to the Vessel Schedule, ETRR/ETR, cloud native transformation and GPE WSs. The WSs shall be extensible and flexible enough to be utilized throughout the IBS and SDDC Enterprise. The WSs security mechanism shall be implemented utilizing the current security implementation used by IBS and follow SDDC standards and best practices for WS security. The Contractor shall develop the software using agile development based on iterative and incremental development methodologies and SOA principles. The Contractor shall develop and deliver documentation for each service which covers description, authentication, error handling, and HTTP information.

Deliverable: Fully functioning tools, modules, and applications available to users via the web greater than 98.5% of the time, continuously beginning at Contract FOC. 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.

There shall be no more than five (5) Medium defects released each contract period.

2.3.2 Task 3 Subtask 2: Sustain Existing System Documentation and Artifacts

Contractor shall sustain, review, and update system documentation, to include all documentation associated with the application including Architecture and Design, User Guides, Administration, Installation, and Maintenance Guides. The contractor shall update interface artifacts based upon system changes within thirty (30) days of changes in procedures/processes. Artifacts shall be and reviewed annually NLT 30 September of each year. User and Training Manual updates are required based upon system updates and Software Change request (SCR) implementation. The updates shall be fielded at the time of the associated SCR’s release; updates shall be fielded with the corresponding production change. System Administrator and Database Administrator Manuals shall be updated as system changes occur and reviewed annually NLT 30 September of each year during the PoP.

2.3.2.1 Interface Artifacts

The Contractor shall update interface artifacts based upon system changes within thirty (30) days of changes in procedures/processes. Artifacts shall be and reviewed annually NLT 30 September of each year. 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. The Contractor shall submit minutes/comments resulting from these meetings to the IBS COR/ACOR electronically. Current IBS Interfaces are defined in Appendix B. The IRS shall conform to the requirements of Contract Data Requirements List (CDRL) A001 (Data Item Description DI-IPSC-81434A, Interface Requirements Specification (tailored)).

2.3.2.2 User and Training Manuals

The Contractor shall maintain and update all user and training manuals in an approved Microsoft Products and Portable Document Format (pdf) versions of the documents when required. These include any manuals/pamphlets affected by any change(s) or update(s) to IBS. The Training Manuals shall include practical exercises containing data files realistic to the functions being explained/taught. The Contractor shall update manuals based upon system updates and software change requests (SCR). All manuals/pamphlets shall be updated and stored via a Version Management tracking tool and will be fielded with the associated SCRs. See Appendix C for the current list of User and Training Manuals.

2.3.2.3 System Administrator (SA) Manual

The Contractor shall maintain the SA Manual, to be updated as system changes occur and reviewed annually NLT 30 September of each year during the PoP. The SA Manual shall address but is not limited to the following:

Shutdown and restart Oracle 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, UNIX, Windows and Oracle environment, architecture and access Archive, locations and management of transaction files Daily monitoring, reporting and checklists Rate Load operations and procedures (Reference Attachment 9 - IBS Rate Load Process) 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 Other miscellaneous and/or relevant items

2.3.2.4 Database Administrator (DBA) Manual

The Contractor shall maintain the DBA Manual, to be updated as system changes occur and reviewed annually NLT 30 September of each year during the PoP. The DBA Manual shall address but is not limited to the following:

Adding and dropping roles Recovering database procedures Updating reference files Managing cyber security via DBA Application and user roles in Oracle environments Creating and managing table space, user accounts, and privileges Database instance install and configuration procedures Rate load operations and procedures (Reference Attachment 9 - IBS Rate Load Process) 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

2.3.2.5 Operational Analysis and Operational Analysis Reports

The contractor shall perform operational analysis following any sustainment and maintenance or other system changes, to include new development, enhancement, security, or other changes discussed in Sections 2.2, 2.3, 2.4, 2.5, 2.6, or 2.8, to include all subtasks. The analysis shall identify IBS operational data issues resulting from system changes. The Contractor shall perform analysis for all IBS sustainment and maintenance changes. The contractor shall work with the Government Lead to determine if changes are required to IBS and its interfaces with other SDDC systems, and shall initiate appropriate SCRs. As part of the analysis effort, the Contractor shall incorporate all information produced into the appropriate IBS system documentation and artifacts and provide Operational Analysis Reports to detail findings. The Contractor shall also maintain functional requirements and the Interface Requirements Specification (IRS) documents for all sustainment and maintenance changes required for IBS.

The Contractor shall submit to the Government:

Proposed changes that the Contractor believes will improve the efficiency and/or performance of IBS or resolve software/hardware problems which have the potential for causing system failure or situations which will improve the overall performance of the system.

Proposed system and process changes where IBS may take advantage of code sharing and/or re-use, data or database table sharing; presentation changes focusing on uniformity in look and feel across multiple applications; and design and development practices that focus on overall improvements and advantages in system integration across multiple applications.

Where SOA principles, methodology, and WS can be incorporated and utilized for interoperability and reuse.

Analysis that provides initial and secondary impact statements on changes, identifying the changes and the projected number of man-hours/level of efforts required to complete.

The Contractor shall create, maintain, and update operational analysis reports in the format and location (i.e., as a stand-alone report or as input to existing technical documentation) designated by the IBS PMO within thirty (30) days of changes in procedures/processes, system updates, and SCR implementation.

Deliverable: Create, maintain, and update system technical documentation, to include associated manuals, interface artifacts, and operational analysis reports based upon system changes within thirty (30) days of changes in procedures/processes, system updates, and SCR implementation. Documentation and artifacts shall be reviewed and updated a minimum of annually, NLT 30 September of each year.

2.3.3 Task 3 Subtask 3: System Integration

The Contractor shall perform system and data integration tasks necessary to assure IBS applications meets the technical, and performance requirements established by the G6 Ocean Cargo Branch. This includes ensuring accessibility through Electronic Transportation Acquisition (ETA) single sign on, 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.

2.3.4 Task 3 Subtask 4: System and 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 but not limited to Development, Staging, QA, Fail-Over, and Production, both On-Prem and in the Cloud as stated in Section 1.2, Scope. The Contractor shall provide Systems Analysis and Engineering Support in the maintaining, updating and documenting the hardware and software associated with IBS Development, Staging, QA, 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.

2.3.5 Task 3 Subtask 5: System and Database Administration

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, Staging, QA and Fail-Over Sites in the appropriate on premises and/or Cloud native environments. Administrational tasks shall be performed in the Development, Staging and QA and Fail-Over Site on premise and cloud native environments during the PoP. The Contractor’s responsibilities shall include, but are not limited, to the following:

a) Production

The IBS Contractor shall perform IBS Application maintenance and updating.

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

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

b) Staging The IBS Contractor shall perform IBS Application maintenance and updating.

Assist in satisfy STIG requirements and patches.

c) Development The IBS Contractor shall perform IBS Application maintenance and updating.

The Contractor shall perform IBS operating system and the database maintenance, updating, patching and documentation.

Satisfy and implementing STIG requirements and patches.

End to end operations and maintenance.

Document connectivity of all installed devices.

d) Fail-Over The IBS Contractor shall perform IBS application and Database maintenance and updating.

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 staging, production and Fail-Over environments by working 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.

2.3.6 Task 3 Subtask 6: Operating, Systems, RDBMS and Application Tuning

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. 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 ORACLE RDBMS to ensure that IBS is operationally sustained for high performance levels. This includes all database documentation to track performance and tuning of database changes. Defect levels are defined in Appendix E.

2.3.7 Task 3 Subtask 7: Maintain Disaster 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 Fail-Over site. The Fail-Over site is located at a separate facility and shall be accessed remotely. 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, continuously beginning at Contract FOC. 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. There shall be no more than five (5) Medium defects released each contract period. Defect levels are defined in Appendix E. The Contractor shall validate that data replication is occurring.

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

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

Deliverable: Update the Fail-Over site to reflect IBS system changes within one (1) day of production implementation. Fully functioning tools, modules, and applications available to users via the web greater than 98.5% of the time, continuously beginning at Contract FOC. 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. There shall be no more than five (5) Medium defects released each contract period

2.3.8 Task 3 Subtask 8: Disaster Recovery/Contingency Plan (DRCP)

The Contractor shall update (and rename if necessary) the existing IBS Disaster Recovery/Contingency Plan for disaster recovery and/or contingency operations in coordination with the enterprise Disaster Recovery Exercise (DRE) solution and the Enterprise Integration Program (EIP) team. The Disaster Recovery/Contingency Plan shall be updated within ten (10) days of the DRE schedule being published. The plan shall include: crisis emergency management (onsite and offsite) (technical and functional); disaster recovery; pre and post emergency operations requirements; and Fail-Over management.

Deliverable: Update the DRCP within ten (10) days after DRE schedule is determined.

NOTE: The existing DRCP may be known by another name, such as the DRE Plan.

2.3.9 Task 3 Subtask 9: Contingency Operations and DRE Support

2.3.9.1: Contingency Operations

The contractor shall, upon request, provide up to 24x7 around the clock support to the Government during contingency, emergency, or Disaster Recovery operations as required IAW the approved IBS DRCP and command contingency operations plans. 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.

2.3.9.2: DRE Support

The Contractor shall plan, coordinate, and participate in the SDDC DRE as required. The DRE is typically a semiannual event. The Contractor shall maintain a white list; ensure authorized service interruptions (ASIs) are planned, documented, and executed; submit firewall requests, and complete necessary actions to support firewall modifications. The Contractor shall participate and execute the SDDC G6 DRE for IBS. The exercise is an opportunity to ensure the plan is executable. The Contractor shall perform activities as required by the plan. The exercises are normally conducted over a one-week period, during normal work hours.

2.3.10 Task 3 Subtask 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 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 Service Now) 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 but not limited to 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, but is not limited to, 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 will be elevated to Tier III.

Estimated requirement is to solve 800 Tier II/III helpdesk tickets yearly.

2.3.11 Task 3 Subtask 11: Federal Information System Controls Audit Manual (FISCAM) and FIAR Support

To ensure the proper operation of IBS, IBS must comply with FISCAM guidance for FIAR auditability. FISCAM is consistent with National Institute of Standards and Technology's (NIST) guidelines for complying with the Federal Information Security Modernization Act of 2014 (FISMA). 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. Contractor will 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 with current FISCAM guidance. 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; 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 will 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.

2.3.X Task 2 Subtask X: Data Analysis

The Contractor shall develop queries and reports using tools provided by the Government in support of operations for IBS applications. Perform reports queries as requested by the IBS PM and IBS stakeholders, which shall include but is not limited to:

Historical/Archived reports - Operational/Sustainment data Data calls

2.4 Task 4: Enhancements (LH)

Contractor shall design, engineer, and implement secure applications, capabilities, and configurations IAW current DoD guidance for both legacy and cloud native transformation suites of systems. This list includes but is not limited to software, technologies, processes, applications, capabilities, databases, interfaces and web services.

These applications and capabilities provide automated tools to support carrier contract requirement definition, rate and service solicitations and evaluation; input vessel schedules; update vessel information; book unit and sustainment 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, GTMO and Multi-Modal contracts cited as a separate Capital Investment task in Section 2.2, custom databases, new/updated interfaces, web pages, reports, and applications to streamline or supplement SDDC business processes. The Contractor Lead 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 CCB priorities. SDDC stakeholders, the PMO and the Contractor will review high priority projects via the SCR form, for development evaluation. The IBS program has a number of open SCRs for new capabilities. The SCRs shall conform to the requirements of Contract Data Requirements List (CDRL) A002 (DI-MISC-81807 (tailored), Software/Firmware Change Request.

Typically, major or complex changes to IBS applications have included, but are not limited to, additional data sources (interface partners), additional reports to support new customers, migration of capability from other programs to eliminate duplicative efforts, and new capabilities based on application changes or business needs.

Major changes within the IBS program average greater than 160 man-hours to develop. Minor or routine changes have included, but are not limited to, report updates, addition of new data elements already available…