Atch 1 - PWS.docx

PERFORMANCE WORK STATEMENT (PWS)

FOR

SURFACE DEPLOYMENT AND DISTRIBUTION COMMAND (SDDC)

GLOBAL FREIGHT MANAGEMENT (GFM)

16 February 2024

PERFORMANCE WORK STATEMENT (PWS) SDDC

GLOBAL FREIGHT MANAGEMENT

Table of Contents

PERFORMANCE WORK STATEMENT GLOBAL FREIGHT MANAGEMENT

Scope of Contract:

The contractor shall provide System Development, Maintenance, and Sustainment for Global Freight Management (GFM) System. This shall include comprehensive, high-quality software for GFM related transportation systems, technical services and Software Development Life Cycle (SDLC) management support of the GFM system and software applications to comply with the Joint Chiefs of Staff planning doctrine, to implement SDLC and Transportation Component for applications as classified above and managed by the GFM Program Management Office (PMO). The contractor shall also implement SDLC and Transportation Component Command (TCC) requests for new capability and enhancements to existing capability, and to prototype new algorithms to improve the veracity of transportation planning and report results effectively in order for the government to make critical implementation decisions.

The PWS includes the following task areas:

Task Area 1: Contract Level and Project Management Task Area 2: GFM Application Sustainment Task Area 3: Enhancements Task Area 4: Emerging Capital Projects (Labor Hour) Task Area 5: Application and Oracle System Operations and Maintenance Task Area 6: Configuration Management (CM) Task Area 7: Information Assurance (IA) Task Area 8: Contract Transition and Knowledge Transfer

1.0 Background

Surface Deployment and Distribution Command (SDDC) is the surface transportation component of the United States Transportation Command. SDDCs primary functions include worldwide port operations, global traffic management, deployability engineering, and development of integrated transportation systems. SDDCs Deputy Chief of Staff for Information Management - Chief Information Officer (IM/CIO) supports SDDC’s mission by designing, developing, implementing, and operating standard Department of Defense (DOD) transportation systems for which SDDC has been assigned responsibility. The Surface Cargo Branch supports the SDDC mission by managing GFM. GFM is the capstone automated execution system of the Defense Transportation System (DTS) for the movement of domestic freight. It is also used to a certain degree as an outside the continental United States (OCONUS) shipping tool. Users access the GFM system through Transportation Enhanced Authentication Management Services (TEAMS) System via an Internet connection 24 hours a day, 7 days a week. GFM currently supports the development, testing, staging/non-prod, and production for all small applications in traditional data centers (physical) and Dev/Ops in a Cloud Computing environment (virtual). The services provided within the scope of this contract are considered Operationally Critical Support (OCS) and Covered Defense Information (CDI) as defined in Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012, "Safeguarding Covered Defense Information and Cyber Incident Reporting.”

GFM is a complex, n-tiered system comprised of many components. The GFM system is comprised of 24 applications sustained by the Contractor. Most of these applications are developed using Java, which are hosted on Apache and Tomcat application servers. Many trading partners interact with GFM using Electronic Data Interchange (EDI) and eXtensible Markup Language (XML) files for ASCII X12 and Web Service data exchanges. GFM uses Axway to translate between EDI and a User Defined Format (UDF) and Java EDI (JEDI) to move the data between the translator and GFM servers. SDDC Enterprise Support division maintains Axway for SDDC programs that require EDI translation service. GFM has approximately 792K lines of Java code.

1.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 GFM tasks outlined in this PWS.

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

The phrases “Government environment(s)” and “GFM environment(s)” or word “environment(s)” refers to Cloud hosted environments. The contractor may have to sustain GFM simultaneously with Cloud operations.

Sprint: A defined amount of work to accomplish one or more user stories. Multiple user stories can be accomplished within each Sprint based on the complexity of the user stories.

Release: Production implementation of software changes that are the result of one or more Sprints. Sometimes a Sprint results in code changes that cannot be pushed to production on their own. In this case, multiple Sprints will occur before the code is implemented in production.

Risk Management Framework: (Presented in NIST SP 800-37) RMF provides a disciplined and structured process that integrates information security and risk management activities into the system development life cycle. The 7 steps of RMF lay out the process an organization must follow: prepare, categorize, select, implement, assess, authorize, monitor.

1.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 Application Sustainment, Enhancement, Development Methodologies and Processes

1.3.1 General requirements

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

The contractor shall provide concurrent development efforts with multiple development lanes. Each development lane will fulfill requirements for independent Sprints. The contractor shall enhance and improve the existing GFM application software and/or its applications to ensure maximum system optimization. The contractor shall conduct all software development entirely within the consolidated /SDDC Government environments. The contractor shall be responsible for the successful installation and implementation of government-owned application software onto the government-owned environments. The contractor may access remotely from their facilities through a government approved Virtual Public Network (VPN) connection and from isolated dedicated development workstations that comply with Government security guidelines.

The contractor shall make changes as functional requirements and business operations change for all legacy and cloud native products as defined and directed by the COR/ACOR and GFM PMO. These changes may include but are not limited to software, tools, applications, servers, interfaces and databases for all GFM applications and related functional tools in support of the GFM user community and the GFM PMO.

The contractor shall maintain/sustain GFM Production and Non-Production environments, assist in urgent analysis for the GFM, and optimize operation and resource utilization. Daily activities include application configuration and operation. Software development and maintenance shall not cause a degradation of the current systems performance. Performance tuning shall be conducted to obtain systems optimization for maximum application workload while maintaining historical performance data to be used as a benchmark.

All deliverables identified in the PWS shall be prepared and submitted for Government approval IAW the applicable Contract Data Requirements List (CDRL).

1.3.2 Acceptance testing and documentation

The Government will perform Government Acceptance Testing (GAT) prior to every Sprint release regardless if the release is going to be deployed to Production or not. As long as there are items that can be tested either thru the user interface/aka manual testing, as part of a provided or consumable service (aka webservice testing), or as part of an Electronic Data Interchange (aka EDI). The contractor shall develop the requirements in a manner that clearly state a user story and associated acceptance criteria for all tasks included with each sprint. This information will be clearly defined and articulated in the developer task management tool and for transparency kept accessible to all concerned. The development team will continue to mature the requirements thru the development process until the sprint completes the development testing (aka QA). Upon completion of QA the requirements as defined in the resource management tool will be reviewed and made final. The development team will also provide a comprehensive test plan and test report which will explain how each acceptance criteria was validated. This should explain the method of testing (i.e. manual, web service, EDI, or combination thereof), the process/steps for doing so and a clear indication that the intent of the task was successfully accomplished. Additionally, the development team shall conduct a degree of regression testing to ensure no adverse impact has occurred to the existing baseline due to the new software changes. A summary of this regression testing should also be included in the test report. The development team, PMO and ETT members shall use the requirements as defined in the task management tool as the source document for changing the software (development), and validating the changes meet expectation (QA and GAT). The Development team’s functionals will be responsible for maturing these requirements so that all parties have a clear vision of the need. They will also work with the test team to ensure a clear vision on what the acceptance criteria will be and the developers to ensure the solution meets all the above. The test team will be responsible for validating the acceptance criteria has been met and provide adequate notes in the task management tool so that it clearly understood what the was done and observed during testing. The PMO, Enterprise Testing Team, and Contractor shall work together to create, use 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. An automated and/or webservice project will be delivered for each sprint.

The contractor shall continuously maintain and update documentation on the architecture of interfaces, data and software. 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.

For all deliveries, the contractor shall provide all source code and documentation (including those related to architecture, test design, test plan and testing results, and installation procedures). The contractor shall have zero major defects on the base-lined software released to Production and shall ensure IA requirements are applied as detailed in PWS.

2.0 Specific Tasks

2.1 Task Area 1: Contract Level and Project Management (FFP)

This task consists of the functional activities relating to the administration and management of this effort.

The contractor shall

· Provide program management for all contractor tasks, personnel resources and ensure all deliverables meet schedule.

· Designate a principal point of contact for technical/engineering issues.

· Provide support by preparing documents such as required briefings, point papers, training aids, and meeting minutes.

· Provide a Contract Manager who shall be responsible for the performance of the work. The name of the Contract Manager and alternate(s), who shall act for the contractor when the Contract Manager is absent, shall be designated in writing to the COR.

Government personnel will make all final decisions regarding project requirements and/or actions. The COR will submit the required evaluations and recommendations to the Program Manager and/or Contracting Officer (KO) for further action.

2.1.1 Task 1 Subtask 1: Monthly Status Report (MSR)

The Contractor shall provide the status of all work under this subtask in an MSR, delivered to the Government no later than the 10th business day of each month. The status shall list, by each active subtask area, the accomplishments of the reporting period. It shall list issues, problem areas, and items that require Government action. It shall also contain a report of the costs submitted on the invoice for that month, traceable to the Contractor Work Breakdown Schedule (CWBS) and Integrated Master Schedule (IMS). The format will be agreed upon by the Government and the Contractor and shall contain the following information:

a. Deliverables

b. Summary of accomplishments

c. Cost Report, traceable to CWBS

d. Summary of CWBS

e. Meetings attended with a summary of relevant items discussed

f. Proposed activities, including requested changes to CWBS

g. Risk register, assessment and mitigation recommendations

h. Open issues

i. IMS Task Summary

2.1.2 Task 1 Subtask 2: Master Release Schedule (MRS)

The contractor shall develop an MRS in Microsoft Project format that provides a schedule for all major milestones as currently tasked to the contractor, for a minimum period of 12 months into the future. This shall be delivered to the Government twenty business days following contract start. MRS updates to delivered as an appendix to the MSR. It also shall include anticipated future work to support schedule and workload deconfliction. The MRS shall include a Master Schedule that lists the major milestones and completion dates associated with each. The MRS shall also include sub-tasks necessary to achieve the milestone and scheduled completion dates for each sub-task. The MRS delivered to the Government shall address each task to include development, test, and deployment for software candidate releases and patches containing approved new capability, enhancements, or problem reports, and shall show the critical path. The contractor shall keep this schedule current, making schedule changes as necessary after coordinating these changes with the PM. The MRS delivered shall include projected tasks for the next 12 months. Any changes must first be coordinated through the PM/COR/ACOR. 95% of all Sprints and other scheduled events/projects shall be accomplished IAW the MRS.

2.1.3 Task 1 Subtask 3: Quarterly Program Management Reviews (QPMRs) The contractor shall schedule and conduct quarterly 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 TFMS Program Manager (PM) no later than two (2) business days prior to the meeting, and minutes of the PMR no later than five (5) business days after the meeting.

2.1.4 Task 1 Subtask 4: Web-Based Application Lifecycle Management Solutions (WBALMS) The contractor shall use the Government provided WBALMS to prepare release candidate roadmaps, to define requirements, project and organizational resources, schedules, and dependencies throughout contract execution. (Currently SBM and JIRA). The government is exploring the move to Service Now as a new Web-Based Application Lifecycle Management Solutions. The process solution of exporting data from SBM and uploaded into Service now has not been finalized. We are wanting the vendor to transport all of the data over. If this is not possible the use of excel spreadsheets to import data may be required. The Contractor shall import/populate the initial product backlog into the WBALMS within 20 business days following contract start.

2.1.5 Task 1 Subtask 5: Integrated Product Team (IPT) Meetings The contractor shall participate in weekly IPT meetings at the Government site or utilizing a web collaboration platform (example: Microsoft Teams) when scheduled by the Government. Meetings typically last 30 to 60 minutes and topics may include updates on progress, requirements management, metrics, MRS, upcoming calendar events, and other pertinent issues as agreed upon by the Government.

2.1.6 Task 1 Subtask 6: Employment Status Report

The contractor shall provide an employee status report (listing/spreadsheet) containing names and labor categories of personnel supporting the tasks identified previously. The report shall be provided within thirty (30) calendar days after contract start and updates to the COR/ACOR no later than 4:00 PM central time the first business day of the following week after contractor staffing levels or personnel are changed. The Employment Status Report shall contain a list of attributes for each staff member including: Name, Position, Company, Location (Remote/On-site), Cubical, Start Date, CAC Expiration Date, Security+ Expiration Date, CE Certification (Required/Not Required/Completed), Cyber Training Completion Date.

2.1.7 Task 1 Subtask 7: Sprint scheduling and status reports

The contractor shall schedule Sprints in coordination with the Development Release Schedule and Contractor Work Breakdown Structure (CWBS). The Release Schedule will incorporate and account for Government acceptance testing prior to every software release.

2.1.7.1 The contractor shall continue to provide a weekly status report within 30 business days following contract start reflecting all development and sustainment efforts followed by weekly status report due every Monday. In addition to non-Sprint efforts, the report should detail ongoing Sprint Team efforts and scheduling of all future Sprints. The weekly status report will identify any issues preventing software development and sustainment efforts as well as proposed resolution efforts.

2.1.7.2 The contractor shall meet the schedule in accordance with the PWS and Master Release Schedule. Any expected delays shall be coordinated with the Government and approved by the PM/COR/ACOR by email. The contractor must provide a plan of action to get the project/requirement timeline back on track in line with the Master Release Schedule.

2.2 Task Area 2: GFM Application Sustainment (FFP)

To support GFM’s reliability during the contract life cycle, the contractor shall:

· Ensure development resources are available to address any production/change requests within GFM.

· Participate in product grooming of the product backlog prior to each Sprint and/or Kanban event in coordination with the PMO.

· Participate in Sprint/Kanban review and retrospective at the end of each Sprint in coordination with the PMO.

· Provide updates at least two times a week to the Government Program Management Office. Depending on the health of the system, the Government may dictate additional updates as required.

During the sustainment period, the contractor shall provide enhancement, integration, test (including unit, regression, and integration testing), and documentation for all GFM software. The contractor shall ensure that the GFM software is compatible with the current and any projected SDDC software configurations (e.g., USAF, SDDC, network, security, Internet browsers). The Government will furnish the contractor with the approved SDDC software configurations.

GFM requires systems administration and analysis support for the Production, Testing, Simulator environments during the period of this contract.

Note of reference: Historically averaged two maintenance releases per month. For estimation purposes, between 12 and 24 maintenance releases occur every year outside of core hours, r being 6 hours in duration.

NOTE: Historically for FY23: 200 Sustainment fixes and 207 CM requests.

The GFM suite of interoperable systems consists of the applications described in Appendix A, GFM Application Descriptions. The System Environment Description is in Appendix B.

The contractor shall:

· Maintain, sustain, and update all GFM applications, databases, and technologies.

· Provide software engineering services and support to ensure the GFM complies with U.S. Laws, Agency Policy, statutory, regulatory, and user requirements required to accomplish the existing mission and minimize operation risk.

· Maintain software, tools, applications, servers, interfaces, and databases for all GFM applications and related functional tools in support of the GFM user community and the GFM Program Management Office (PMO).

· Comply with SDDC Enterprise Architecture Standards for database design; perform all development using ANSI and DOD standards.

· Apply agile and iterative development methodologies in order to provide timely capabilities to the user community and the warfighter.

· Ensure that information systems security engineering is employed during all changes to the system and software development life cycle.

2.2.1 Task 2 Subtask 1: Functional Requirements and Documentation The contractor shall sustain, create, review, and update system documentation in accordance with this PWS for Sustainment, Enhancement, New projects and Accreditation.

The contractor shall:

· Review change requests ensuring understanding of functional and user requirements.

· Be responsible for performing system/functional analysis and creating/documenting user stories/acceptance criteria in support of agile development efforts. These descriptions shall translate functional requirements received from the PMO based on the needs of the customer. Each requirement will be documented in Solutions Business Manager (SBM).

· Prepare technical documentation within 30 business days following contract start and delivered to the Government for the GFM Projects to include System Requirements, System Manuals and processes, Interface Requirements, Database Description Documents (DDD), Flow chart, Checklists, Web Services documents, System-user documents and other GFM system documentation requested by the program management team. Existing documents such as Memorandum of Understanding (MOUs), The Interface Design Document (IDDs) and Interface Requirements Agreement (IRAs) will be provided to the Contractor at the beginning of the contract. Documents will be stored on the SDDC provided repository.

· Prepare and maintain Standard Operating Procedures (SOPs) to ensure consistency of system performance. Activities related to hardware and software configuration shall be documented. SOPs shall include: code standards, code scans, code promotion, backups and restores, baseline changes, licensing, installing software, and applying patches. SOPs will be updated and delivered two times per year. (31 Mar & 31 Aug of each fiscal year)

· Prepare artifacts and documentation required for the RMF Process. This includes ATO accreditation packages, continuous monitoring and IATTs. Some examples of this will include: hardware list, software list, PPS, STIG Applicability list, program topology, etc. ATO package submissions are required based on each ATO expiration e date per the USTC provided schedule.

· Prepare and maintain detailed Interface Requirement Agreement (IRA) documents for each interface between GFM and its trading partners. The contractor shall maintain and update this information in the designated CM tool. Signed documents will be stored electronically on a government-owned server to be designated by the COR. Changes to a document will be made by a complete revision and identified by unique Document History Control Number. The justification for the modification is to be recorded in the Document History. If no change proposals are submitted during the annual review period, that fact is to be noted in the Document History and the document will be notated Reviewed on (date) with no change required.

· Document server application configuration changes for each server within the GFM environments.

· Provide a server application configuration change document when configuration changes are implemented and deliver to the Government and stored in Government provided storage location.

· Prepare and maintain system architecture diagrams, system documentation, and other system- related documentation and deliver to the Government and stored in Government provided storage location currently on SDDC SharePoint site located: SDDC Org Share HQ - Home (sharepoint-mil.us) - (https://armyeitaas.sharepoint-mil.us/sites/SDDC_Fileshare_HQ).

System Administrator (SA) Manual The contractor shall maintain the SA Manual. The SA Manual shall address:

· Install application code, or packaging for CE SAs to install

· GFM System startup procedures

· User interfaces

· Standard Service Level Agreement (SLA) agreements with SDDC Enterprise Integration Program (EIP)/CE team

· Applicable items for other SA to be able to perform duties

Database Administrator (DBA) Manual The contractor shall maintain the GFM DBA Manual. The DBA Manual shall address:

· Shutdown and restart GFM database servers or instances

· Recovering database procedures

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

· Database install and configuration procedures

· Create and maintain a list of business rules as applied by Database and/or User Interface (UI). The rules should be broken down as appropriate by table, field, application and form. This is a living document and delivered/updated within 7 business days after release

· Applicable items for other DBA to be able to perform duties

2.2.2 Task 2 Subtask 2: Interface & Electronic Commerce/ Electronic Data Interchange (EC/EDI) Support

The contractor shall support the current data exchange capabilities in GFM. These are currently done via Electronic Data Interchange (EDI) exchanges, Extensible Markup Language (XML), and Web Services.

The contractor shall:

· Perform an assessment of the existing interface data exchanges for a migration to web services in accordance with the SDDC Application Modernization Strategy activities and metrics: Decomposition of Application to Micro-Services; All Data Exchanges Identified; All Data Exchanges Converted to Web-Services; and All Web-Service Exchanges via the Enterprise Service Bus (ESB), TomCat, or the Enterprise Delivered to the Government no later than the thirty (30) business day of request.

· Create and maintain User Defined Format (UDF) business logic and crosswalk mappings that comply with the Defense Transportation Electronic Business (DTEB) Implementation Conventions (ICs) for Electronic Data Interchange

· Be responsible for the day-to-day processing of data exchanges within the GFM domain and its trading partners and ensure all inbound transactions are retrieved, processed and stored. Note, with the direction from the PMO, the contractor may need to coordinate with outside supporting agency during Electronic Data Interchange (EDI)/UDF trouble events.

· Support the Enterprise EDI team (EET) and Enterprise Interface/Data Architecture teams as needed for day-to-day receipt, distribution, and resolution of data exchanges outside the GFM domain.

· Provide support for existing and new schemas and Web Services Description Language (WSDL) to ensure accurate data exchanges between GFM and its trading partners.

· Ensure all data elements are recorded in the schema and WSDL comply with GFM business requirements and enterprise standards.

· Update existing or creating new XML to ensure accurate data exchanges between GFM and its trading partners.

· Ensure schema, WSDL and XML are updated or creating support the procedures and requirements prescribed to Transportation Service Providers (TSP), providing commercial transportation and related services to the Department of Defense (DOD) and other authorized users of the Defense Transportation System (DTS), as published in the Defense Transportation Regulation-Part II and Military Freight Traffic Unified Rules Publication-1 (MFTURP-1).

· Ensure all data elements are recorded in the UDF comply with GFM business requirements and enterprise standards.

· Ensure all inbound and outbound EDI/UDF transactions are retrieved from and/or deposited in the appropriate directory on a GFM server or the Managed File Transfer server (MFTS). Ensure the transactions are successfully processed into/generated by the GFM system. Note, with the direction from the PMO, the contractor may need to coordinate with outside supporting agency during EDI/UDF trouble events.

· Perform root cause analysis on data and the underlying business issues spanning multiple GFM applications, schemas, or interfacing systems.

· Ensure all inbound and outbound XML and web service transactions are deposited in and retrieve from the appropriate directory on a GFM server or SDDC Enterprise Service Bus (ESB).

· Support the technical infrastructure needed to support Electronic Commerce (EC)/EDI.

· This support shall include personnel that possess detailed technical knowledge of EDI ASC X12 Transportation Standards, DOD Implementation Conventions, data requirements, and software associated with the system.

· Provide software monitoring and assist the enterprise EDI teams as needed in support, upgrade and trouble shoot GFM EDI.

· Coordinating changes to the Trading Partner profiles Master Files within the Enterprise EDI translator tool, initiate, establish and maintain GFM Trading Partner interfaces using secure shell, creating and maintaining Unix shell scripts to transfer and consolidate files between GFM zones and the Command Run On (CRON) jobs that schedule them, maintenance of customized Unix shell scripts to start up and shut down the current SDDC EDI translator tool.

· Collaborate with outside agencies with coordination through the PMO to research/validate issues impacting EDI transactions.

· Setup interfaces for outbound and inbound system traffic.

See Appendix D for GFM Trading Partners See Appendix E for GFM Data Exchange Templates

2.2.3 Task 2 Subtask 3: User Training and Training Manuals - Distant Web Learning The contractor shall maintain the Distance Learning Program (DLP) for the GFM suite of applications in Appendix A. The manuals and guides are maintained in soft copy format. The contractor shall:

· Ensure integration of these products with the existing developmental strategies of GFM and current training.

· Ensure that all training and learning tools are updated consistent with and are synchronized with each software upgrade and each version release.

· Maintain or create user interactive training modules for all current and/or future GFM applications.

· Interactive training modules are the primary method for user training.

· Training modules include practical exercises containing data files that are consistent with the application and realistic to the functions being explained to the user.

· No less than five times per month, the contractor shall conduct training in support of users. Typical class time is approximately two hours. Trainings are typically conducted via an online collaboration tool (example: Microsoft Teams).

2.2.4 Task 2 Subtask 4: System and Database Administration

The contractor shall perform all SA and DBA on GFM Development Enhancements, Quality Assurance (QA), Consolidated Training (CTE), Testing and Production site zones/ Environments. Standard zones or virtual servers will be provided to the contractor by the Government’s CE contractor. The contractor shall work with the network management team to configure permissions, user groups and directory structures.

The contractor shall:

· Complete all Application Administration, Oracle Database administration, and uniquely GFM tasks for Oracle and System Administration.

· The Government’s CE contractor is the primary Systems Administrators and Oracle DBAs for these environments.

· Work with the Government’s CE contractor to ensure all databases, Operating Systems (OS), permissions and security are maintained at the appropriate levels.

· Coordinate database backup preparation.

· GFM requires specific database backups to keep the Oracle and databases synchronized on date and time stamp. GFM SA shall prepare data for team to coordinate backups in all environments.

· Monitor the accuracy and timeliness of the backup service provided by the SDDC Systems administration support contract, set-up directory structure and permissions for the GFM Oracle Database environment as well as other GFM applications (See Appendix A), set-up monitoring support tool configurations.

· Perform GFM application maintenance and updating of application patches. Systems Administration tasks that are uniquely GFM in nature, to include required Oracle Database synchronization steps.

· Configure permissions, groups, directory structures and load applications.

· Perform all required patching (excluding operating system) for application, database for Oracle, and any required maintenance, updating and documentation.

· Be fully responsible for maintenance and support of the development instances.

· Maintain VMs, Bastion Host or equivalent instance.

Currently GFM has a development environment that consists of a front-end application tier, a backend database tier, web tier, code repository server and code scanning server. These applications are housed on Solaris or RHEL and Windows virtual server zones.

The contractor shall:

· Propose changes that the contractor believes will improve the efficiency and/or performance of GFM or resolve software/ hardware problems which have the potential for causing system failure or situations which will improve the overall performance of GFM.

· Submit system and process changes where GFM may take advantage of code sharing and/or re- use, data or databases tables 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.

· Identify areas were SOA principles, methodology and Web Services, can be incorporated and utilized for interoperability and reuse.

· Maintenance to the GFM Development, Non-Prod Environment, through database tuning and system patching.

· Load all applications and COTS software within the Development Non-Prod Environment.

· Provide technical support to the CE contractor in install/deploy software patches and releases into all environments.

2.2.5 Task 2 Subtask 5: Tier II/III Help Desk Support

The contractor shall resolve and provide Tier II/III Help-Desk support of Service Requests (SRs) or Problem Reports (PRs) escalated from Tier I status.

The contractor shall:

· Analyze problems reported via Tier I and take corrective actions to restore GFM functionality.

· Make software changes and System/Data Administration actions as required in order to resolve service interruptions, errors or other problems reported by the user community.

· Log problem status and resolution information in the Government owned SDDC ticketing database (Service Now is the current tool to capture this data).

· Identify trends and areas for improvement and include this analysis in the MSR. Noted trends must be analyzed/documented/resolved by the contractor with coordination from the PMO office. Trends are considered five tickets concerning the same issue highlighted from multiple GFM users.

· Perform Help Desk support outside core work hours in case(s) of a system outage.

· Identify on-call personnel for hours outside of the core work hours (07:00 – 16:30 USA Central Time) that will be available via telephone/cell phone. The Government will not provide telephones or cell phones for this service.

· Assist the Government in providing updated information for the maintenance of the End to End Service Management Center Application and knowledge database. Contractor-provided updates will be sent by the Government to PMO/SRC staff for updating the SRC Application and knowledge database.

· Diagnose and fully restore to service any malfunctioning component.

· Provide a PR Analysis and Recommendations each contract performance period with specific, feasible, and actionable recommendations in writing to reduce system factors that create SRs. The Government will determine which recommendations to implement in future software releases. Delivered to the PMO NTL Twenty (20) business days into new FY.

· Analyze and resolve escalated PRs or SRs within five business days after the Tier 2/3 escalation date.

· Provide resolution of open software PRs through maintenance releases with resolutions incorporated into the baseline using software versioning methodology.

· Design system applications and integration efforts to enhance/improve the performance and efficiencies of GFM software modules and applications.

NOTE: Historically, GFM Tier II/III Help Desk support averages 150 Tier II/III call per month.

2.2.6 Task 2 Subtask 6: Unscheduled Outages Events

The contractor shall:

· Resolve unscheduled outage events attributable to the GFM software, customized Commercial Off the Shelf (COTS), or interfaces. The GFM Production environment unscheduled outage shall not exceed a total of four hours per month.

· Analyze each unscheduled outage event (i.e., attributable and non-attributable to the GFM software, customized COTS, or interfaces) to determine and document the root cause of event, event duration, modules affected, volume of accumulated backlog, possible users affected, agencies contacted, and actions taken to resolve the event.

· Utilize the Government-provided tools and coordinate with agencies, activities and resources associated with the event to provide a complete analysis.

· Report the analysis findings in an After-Action Report (AAR) no later than 10:00 AM CT one business day following the day the unscheduled outage event is initially reported to the contractor’s service/help desk. Notify the Government when GFM is operational and accessible to all customers.

· Complete all required application configurations to ensure the GFM applications are correctly installed and configured to operate should primary availability zone fail.

· The contractor shall ensure all databases are replicated to the secondary availability zone to include Oracle, EDI Data, and all applications are maintained at the same level.

2.2.7 Task 2 Subtask 7: Disaster Recovery Exercise (DRE)

The contractor shall:

· Participate in SDDC G6 DRE as directed no more than twice a year.

· Perform contingency operations planning for SDDC IT systems in coordination with the enterprise DRE solution and SDDCs Common Computing Environment (CE). The plans will include crisis emergency management (onsite and offsite) (technical and functional); disaster recovery; pre and post emergency operations requirements; and fail-over management.

· Complete all required application configurations to ensure GFM is correctly installed and configured to operate at the Disaster Recovery (DR) site.

· Provide support to the Government during emergency operations in accordance with approved disaster recovery and contingency operations plans.

· Ensure resources/key personnel are available throughout an emergency in accordance with the established plan. Exact Cloud DRE testing procedures are unknown until programs are migrated to the Cloud.

2.2.8 Task 2 Subtask 8: Data Analysis

The contractor shall develop ad hoc queries and reports, such as:

· Historical/Archived reports Operational/Sustainment data

· In support of Freedom of Information Act inquiries Analysis/impact studies Data calls Requests shall be submitted via the enterprise configuration management tool.

2.2.9 Task 2 Subtask 9: Software Implementation

The contractor shall:

· Provide production ready software to the test environment for Government Acceptance Testing.

· Enterprise Testing will provide feedback to the developers and government team in the form of PRs recorded in the government approved change management tool, on any defects or functionality that does not meet the defined requirements.

· Implement all testable components into the Government’s automated testing tool prior to promotion to the next environment.

· Automated testing shall be handed off to the Enterprise testing manager. Analyze and resolve all defects identified by the Test Team. Corrections shall be provided in a software release or patch, as required.

· Provide an implementation plan that documents the discrete tasks required to install and/or deploy software patches and/or releases that will require system downtime exceeding 15- minutes. The implementation plan shall include:

· Schedule of events by task

· Bulletin, Message of the Day (MOTD), notifying customers and trading partners of the estimated duration and scope of the scheduled downtime.

· Prepare a Software Release package for each software change package and deliver it at the time of software delivery. The package shall include all applications and shall be issued for all releases. In each package, identify each Software Change Request (SCR) number and provide a brief description of the change. Include Step-by-step instructions with acceptance criteria for all functional items. Other items as agreed to with the Enterprise Test Team. These items need to be delivered in draft seven business days prior to Government Acceptance Test start date.

· Provide Software Code Installation Guide(s) 24 hours prior to each release.

· Install software to the Alternate site or equivalent within one day after installation of Production.

· Work with Enterprise Testing on specific release required deliverables depending on the complexity of Data Sets, Workflow Diagrams, and Business rules.

· Support Enterprise Testing with building and maintaining of automated Test Project Library.

2.2.9.1 Task 2 Subtask 9.1: Software Development Unit Test (SDT) The contractor shall:

· Conduct SDT before releasing software to the GFM PMO.

· Provide a Software Development Test Plan, test the software according to the plan, and develop a SDT Test Results Report for each software SCR and/or PR incorporated 24 hours before each GAT release.

· Regression test all software changes and development prior to Government Acceptance Testing.

· Ensure the software is error and abort free and shall verify interoperability and integration with interfacing systems. Development testing should be automated and testing scripts provided to the Government five business days prior to testing. For test cases that cannot be automated, coordination with the PMO and GAT to obtain concurrence.

· Step-by-step test cases, data sets and specific release deliverables in coordination with PMO/Enterprise Test Team.

2.2.9.2 Task 2 Subtask 9.2: Software Reviews and Software Version Description (SVD) The contractor shall:

· Prepare a SVD for each software release and present the SVD to the Government no later than five business days after deployment of the application. The SVD shall identify and describe an inventory of materials to be released, software/applications contents, changes to be installed, adaptation of data, related documents, installation instructions, and possible problems and known errors.

· Conduct software reviews for new development. Software reviews consist of Test Readiness Review (TRR), Fielding Decision Briefing (FDB), Other briefings, walkthroughs, and/or prototype demonstrations.

· Provide meeting minutes no later than five business days after Test Readiness Review (TRR), Fielding Decision Briefing (FDB), Other briefings, walkthroughs, and/or prototype demonstrations.

2.2.10 Task 2 Subtask 10: Bills of Lading (BLs)

The contractor shall:

Provide for electronic transfer of BLs among all GFM trading partners through the development and maintenance of software and the monitoring of BL file transmissions.

· Develop/maintain the capability to cost and select for traffic currently moving under BLs in order to assure that the Government acquires the best value.

· Enable the system to produce electronic and hardcopy BLs.

· Ensure that the electronic files are available for transmission to GFM Trading partners (TPs) – one year active / 10 years archived. GFM is the repository for all BLs.

2.2.11 Task 2 Subtask 11: Remote Carrier Access

The contractor shall:

· Provide the capability for commercial carriers to access the GFM ATR, CAVS, FCRP and TEOW applications from remote locations and obtain shipment Requests and Responses, Standard Tender of Freight Services, and Bills of Lading information.

· Support and enhance the automated process of carriers accessing ATR, CAVS, FCRP, and TEOW via the Internet.

· Establish and maintain user accounts in accordance with Army and DOD security guidelines and regulations and monitor system access patterns. These guidelines and regulations include, but are not limited, to DOD 8500.1, DOD 8500.2, AR 25-2, and AR 38019. All user access shall be positively authenticated and monitored, and non-repudiation must be established. All attempts at non-authorized access shall be reported within 24 hours to GFM PMO personnel.

· Implement system changes as necessitated by IT security notifications, the Information Assurance Vulnerability Management Program or as required by Information Assurance Program Manager (IAPM).

2.2.12 Task 2 Subtask 12: Cloud Environments

Contractors are REQUIRED to meet 8570 or DoDD 8140.01 requirements in the contractor development, Testing, Training and Production…