Atch 1 20240212 AMP IDIQ PWS v1 FINAL.pdf

Attachment 1

HTC71124RD0002

Program Executive Office USTRANSCOM (PEO-T)

Performance Work Statement (PWS)

For

Analysis of Mobility Platform (AMP) Indefinite Delivery Indefinite Quantity (IDIQ)

12 February 2024 FINAL Version 1 ii

Table of Contents 1 Description of Services

Background

1.1.1 Analysis of Mobility Platform Suite of Tools

1.1.2 AMP Analytic History

Objective

Scope

Performance Requirements

1.4.1 Task Area 1: Contract and Program Management

1.4.2 Task Area 2: Technical Support for Studies and Analyses

1.4.3 Task Area 3: Requirements Management Support

1.4.4 Task Area 4: Software Design and Development Support

1.4.5 Task Area 5: Software Maintenance

1.4.6 Task Area 6: Application Administration

1.4.7 Task Area 7: Security Engineering and CyberSecurity Requirements

1.4.8 Task Area 8: Annual AMP Contingency Plan Review Support

1.4.9 Task Area 9: Configuration Management (CM) Support

1.4.10 Task Area 10: Enhancements

1.4.11 Task Area 11: New Capability

1.4.12 Task Area 12: Cloud Migration Support

Deliverables

2 Service Delivery Summary (SDS)

Inspection, Acceptance, and Warranty

2.1.1 Data Protection

3 Government Furnished Property (GFP) and Government Furnished Information (GFI)

Use and Safeguarding of GFE

3.1.1 Privately Owned Computers

3.1.2 Access to Government Services

Government Furnished Information (GFI)

Official Business

Facilities

3.4.1 Secure Communications – Secure Internet Protocol Router Network (SIPRNET)

4 General Information

Place of Performance

Travel

Hours of Operation and Federal Holidays iii

Other Direct Costs (ODC)

Account Management

Section 508 Accessibility

Period of Performance

Latent Defects

Quality Assurance

Acquisition Streamlining

5 Non-Disclosure Requirements

6 Security

Physical, Personnel, Information, Antiterrorism/Force Protection and Industrial

6.1.1 Citizenship and Clearance Requirements

6.1.2 Facilities Clearance (FCL)

6.1.3 Personnel and Facilities Clearance Validation

6.1.4 Common Access Card (CAC) Issuance Procedures

6.1.5 Access to Scott Air Force Base and USTRANSCOM Facilities

6.1.6 Additional Security Conditions

6.1.7 Derogatory Information

6.1.8 Accessing NATO Information

6.1.9 Security Debriefing

6.1.10 Operations Security (OPSEC)

6.1.11 Security Regulation Compliance

6.1.12 NOTE TO THE PRIME CONTRACTOR FACILITY SECURITY OFFICER (FSO):

6.1.13 USTRANSCOM PSC Points of Contact:

USTRANSCOM Incident Handling

6.2.1 Operationally Critical Support

6.2.2 Cybersecurity Incident Reporting

6.2.3 Cybersecurity Incident Reporting Timelines

6.2.4 Mandatory Reporting Data

6.2.5 Incident Reporting Coordination

6.2.6 Confidentiality and Non-Attribution Statement

6.2.7 Subcontracts

APPENDIX A: REFERENCE PUBLICATIONS & APPLICABLE DOCUMENTS

APPENDIX B: ACRONYM LIST

APPENDIX C: NONDISCLOSURE AGREEMENT

APPENDIX D: DOD CYBER WORKFORCE FRAMEWORK (DCWF) CODE ASSIGNMENTS ... 57

1 Description of Services Background

1.1.1 Analysis of Mobility Platform Suite of Tools

The Analysis of Mobility Platform (AMP) is a suite of tools supporting analysis of the joint deployment distribution enterprise (JDDE). Tools range from complex simulation and optimization modeling environments to highly detailed simulation tools. The United States Transportation Command (USTRANSCOM) Joint Distribution Process Analysis Center (JDPAC) is the functional manager for the AMP program, and the tools within the suite include:

• AMP-Core

• Air Refueling Model (ARM)

• AMP-Port Analysis Tool (AMP-PAT)

• Rapid Course of Action (COA) Analysis Tool (RCAT)

• Joint Mobility Closure Estimator (JMCE)

• AMP-Transportation Feasibility Assessment (AMP-TFA)

AMP-Core is a comprehensive transportation modeling, simulation, and optimization environment used to analyze and assess the movement of military-related cargo and personnel within the Defense Transportation System (DTS). Furthermore, it provides a comprehensive representation of end-to-end deployment and distribution, to include movement by all transportation modes within the continental United States (CONUS), inter-theater (strategic), within theater, and combinations thereof. Primary AMP-Core users include analysts at the USTRANSCOM JDPAC, Military Surface Deployment and Distribution Command Transportation Engineering Agency (SDDCTEA), Air Mobility Command (AMC) A9, Joint Staff J4 and J8, Office of the Secretary of Defense (OSD) Cost Assessment and Program Evaluation (CAPE), Secretary of the Air Force Studies, Analysis, and Assessments (SAF/SA), and the Center for Army Analysis (CAA).

ARM models Air Refueling (AR) operations within large, end-to-end JDDE scenarios to address current/future tanker capabilities and CONOPs. The primary use case is to model the impact of AR operations in the context of large programmatic scenarios to determine number of tankers required to support defense planning scenarios and impact of tanker operation on the JDDE, to include fuel, MOG and required strategic mobility assets.

AMP-PAT includes quick-look tools for assessing air and seaport enabler requirements and port throughput, as well as highly detailed simulation tools for airport, seaport, and installation modeling:

• Airport Rapid Analysis Tool (ARAT)

• Airport Throughput Tool (ATT)

• Airport Simulation Tool (AST)

• Seaport Rapid Analysis Tool (SRAT)

• Seaport Throughput Tool (STT)

• Seaport Simulation Tool (SST)

• Installation Simulation Tool (IST)

• Contingency Planning Tool (CPT)

RCAT is built using legacy strategic simulation algorithms from the AMP-Core tool. It is a quick, intuitive COA comparison tool used by planners to rapidly develop and assess transportation COAs.

JMCE is a formula-based, rough order of magnitude (ROM) deployment estimator application.

New to the AMP suite is AMP-TFA. The AMP-TFA application is a cloud-based version of the AMP-Core transportation modeling and simulation tool used to analyze and assess the transportation feasibility of Combatant Command contingency/deliberate operation plans (OPLANs) within the adaptive planning process. A unique, cloud-based GUI and additional features specific to AMP-TFA have been developed to support the AMP-TFA user base. The tool is currently in development and is scheduled to reach Initial Operating Capability (IOC) as DOD’s TFA model of record by the end of FY24.

1.1.2 AMP Analytic History

AMP supports answering force closure, infrastructure, lift asset, process, and policy analysis questions. Analysts use AMP to support a variety of use cases, to include programmatic analysis, deliberate planning, crisis action planning, operational planning, exercises, and war games. AMP-Core has served as the Department of Defense’s (DOD’s) model of record for OSD-level major mobility programmatic studies since 1995, while ARM has been the DOD’s model of record for mobility studies for Tanker Requirement since 2018. AMP-Core theater modeling capability is the long-standing program of record for theater Reception, Staging, Onward Movement, and Integration (RSO&I) analysis.

JDPAC has conducted multiple Research, Development, Test, and Evaluation (RDT&E) projects within the AMP program to infuse mathematical optimization technology within the AMP-Core discrete event simulation environment, resulting in capabilities to enable AMP-Core to optimally allocate and schedule air assets to movement requirements and to optimally make mode and node determination decisions. Analysts can yield solutions which drive effectiveness (velocity), efficiency (least cost), or best value combinations while also accommodating asset readiness constraints.

The AMP program leveraged RDT&E to develop campaign-level AR modeling and analysis capabilities to address such requirements as track switching, tanker-to-tanker refueling, disruptive events, tanker CONOPS/schedule repair, large-scale campaign scenarios, opportune cargo, and AR receiver demand modeling.

AMP has numerous features, all of which have been incorporated to address user requirements.

Following is a short subset of these features:

• End-to-end deployment and distribution modeling environment, accommodating deployment/re-deployment and sustainment/retrograde operations of military cargo and personnel over the DTS.

• Joint Operation Planning and Execution System (JOPES) time-phased force deployment data (TPFDD) movement requirements

• Extensive, detailed, geospatial representation of multi-modal transportation networks and nodes.

• Extensive, detailed representation of organic and commercial lift assets

• Integrated strategic and theater airlift and sealift; channel/Special Assigned Airlift

Missions (SAAM), Voluntary Intermodal Sealift Agreement (VISA)

• Integrated origin-to-destination planners and schedulers

• End-to-end and nodal Discrete Event Simulation (DES)

• Heuristics-based mode and node determination/optimization

• Virtual Requirement Line Number (RLN) unit integrity modeling

• Schedule Optimization (i.e., Mixed Integer Programming (MIP) and Linear Programming

(LP) mathematical optimization integrated within DES) in support of operational airlift, providing effectiveness/efficiency objective trade-offs.

• Network Optimization (i.e., Mixed Integer Programming (MIP) and Linear Programming (LP) mathematical optimization integrated within DES) in support of strategic mode/node/transshipment determination to provide effectiveness/efficiency objective trade-offs.

• Air/Sea trade-offs, multi-modal operations

• Dynamic, multi-echelon organization-based sustainment generation with inventory management and dynamic source selection

• Ashore and afloat prepositioning

• Joint Logistics Over-the-Shore (JLOTS) modeling

• Large (e.g., over 100,000 movement requirements) multi-theater, multi-OPLAN, multi-year scenario modeling, within two-hour run-time

• Simulation start-stop and exogenous event handling.

• Extensive theater Reception, Staging, Onward movement, and Integration (RSOI) modeling

• Costing

• Detailed tabular, graphical, and animation output.

• Air Refueling modeling.

• Extensive Contested Environments (CE) excursion modeling capabilities

Objective The objective of this requirement is to provide software development support and expertise for AMP. This includes all software code and associated components and integrations. Software development support shall include any phase of the Software Development Lifecycle (SDLC), including concept development, planning, requirements elicitation and analysis, systems design and development, coding and testing, deployment, implementation, integration, troubleshooting, security posture, documentation, and software application maintenance necessary to sustain and modify the system baseline. Responsibilities include managing the code baseline, the hosted environment, and system interfaces. The code baseline may change as a result of user preference, latent defects, change requests, security requirements, or updates to Commercial Off the Shelf (COTS) products used by the system. Production support includes troubleshooting and resolving user problems as well as identifying opportunities to improve the system. Close collaboration with other members of the team to include Government Program Manager, Functional Manager, Engineers, Security, end-users, and related technology partners is paramount to contract success.

All references, including electronic libraries, can be found in Appendix A, Reference, Publications, and Applicable Documents. Task orders issues under the AMP support services contract must comply with the most current versions of all references detailed in Appendix A.

Scope The Contractor shall provide elements of agile software development support for AMP, consistent with government guidance and intent to maximize agile development as much as practicable. The Contractor shall provide solution consulting and programming to: (1) implement new system capabilities; (2) implement change requests; (3) sustain deployed capabilities by rapidly troubleshooting and repairing software issues (i.e. correct software defects); (4) provide technical expertise to ensure high availability of the application to meet the USTRANSCOM mission; (5) receive and respond to problems reported by system users (i.e.

correct incidents); and (6) improve the system’s security posture. The Contractor shall provide support in achieving the discipline of Development/Security/Operations (DevSecOps). This support shall include expertise with Platform One Party Bus.

Further, the Contractor shall provide expertise to build and maintain the AMP-TFA development, non-production, and production environments in the Platform One Party Bus cloud environment (and other supporting, similar environments, as appropriate), as well as the DAF Cloud CLOUDWORKS (formerly known as the Operational DevSecOps for ISR NexGen (ODIN)) environment for the Secret Internet Protocol Router Network (SIPR) and the Joint Worldwide Intelligence Communication System (JWICS). While the requirement to host AMP capabilities on a desktop platform is expected to endure indefinitely, the remaining desktop modules of AMP may also transition to Platform One Party Bus as part of a task order written against this IDIQ ordering period (Reference paragraph 1.5.11 and 1.5.12).

The Contractor estimates and timelines shall be determined based on the specific tasks and deliverable due dates specified in each individual task order (TO). The Contractor shall coordinate with the AMP Government Program Manager (PM) and Function Manager (FM) to ensure that all activities are well synchronized and integrated with other USTRANSCOM modeling and simulation (M&S) efforts, and that replicated or overlapping efforts do not occur.

All reports, studies or policies identified in the Performance Work Statement (PWS) shall be prepared and submitted for Government approval or acceptance. All functions and activities shall be task driven and work performed shall be in accordance with (IAW) all applicable regulations and guidelines.

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

Performance Requirements The Contractor shall employ a government directed/approved Application Lifecycle Management (ALM) tool (currently Jira) to effectively manage and execute SDLC processes to analyze requirements, decompose large requirements into logical sub artifacts, create user stories level artifacts and technical specifications (i.e. Epics or large features must be decomposed into user stories), coordinate with the appropriate subject matter experts (both technical and functional) to receive approved acceptance criteria for Epic/Task/Subtask level artifacts, set level of effort, develop and test software, create test scripts and implement User Acceptance Testing (UAT), and keep artifact statuses updated (artifacts are the method for identifying a change with software which will be deployed into Production). To maintain schedule, the Contractors shall complete the artifacts they commit to in each software release, and team members are encouraged to collaborate towards requirements completion. User stories and design documentation shall be maintained within the ALM tool. The technical release documentation shall document all changes and procedures necessary to promote a release into production.

The Government will assign requirements to the Contractor for fulfillment via entry into the provided ALM tool and after approval through the Backlog Grooming (BLG) process.

The software development releases are defined by the Government and result in software releases. The Contractor shall typically provide up to four (4) minor releases, up to six (6) scheduled maintenance releases, and up to six (6) emergency releases annually; emergency releases will occur between regularly scheduled releases.

Version numbering shall be consistent with the description contained in the Government Configuration Management Plan (CMP).

Each TO shall include the scope of one or more of the task areas listed below. Specific tasks shall be specified and performed under individual TOs.

• Task Area 1: Contract and Program Management

• Task Area 2: Technical Support for Studies and Analyses

• Task Area 3: Requirements Management Support

• Task Area 4: Software Design and Development Support

• Task Area 5: Software Maintenance

• Task Area 6: Application Administration

• Task Area 7: Security Engineering and CyberSecurity Requirements

• Task Area 8: Annual AMP Contingency Plan Review Support

• Task Area 9: Configuration Management (CM) Support

• Task Area 10: Enhancements

• Task Area 11: New Capability

• Task Area 12: Cloud Migration Support

1.4.1 Task Area 1: Contract and Program Management.

This task area shall encompass overall contract management that tracks the performance of the work. The Contractor shall provide all services, personnel, planning, direction, coordination, and control necessary to provide the services required by this contract. The Contractor shall designate a Program Manager (CPM) who is the authorized point of contact (POC) with the Government Contracting Officer’s Representative (COR). The PM shall be responsible for the cost, schedule, and technical performance for the contract and shall serve as a primary POC for both management and technical matters. The CPM responsibilities include, but are not limited to, interfacing with Government management personnel, staffing of all tasks, formulating, and enforcing work standards, creating personnel and project schedules, reviewing work discrepancies, and communicating Government policies, purposes, and goals to the Contractor team. The CPM shall provide necessary support and oversight in performance execution of the AMP effort.

Program Management Plan. The Contractor shall develop a plan documenting the Contractor’s management approach, operating procedures, staffing approach, and overall work Breakdown Structure. Staffing Plans regarding resource assignments by task may be required at the task order level.

Task Order Management Plan (TOMP). The Contractor shall prepare a TOMP describing the technical approach, organizational resources, and management controls to be employed to meet requirements of each task order. The Contractor shall maintain an Integrated Master Schedule (IMS) to plan out new system capabilities, functionality changes, system maintenance, and/or product upgrades at the task order level. The IMS shall include all planned releases for the following year at a minimum.

In-Process Reviews (IPRs). The Contractor may be required to participate in IPRs where the status of the work and associated deliverables is reviewed with Government leadership. At a minimum, the IPR shall summarize status, progress, recommendations, financial summaries, and concerns in the development of any tasks or documentation described within in this PWS and any active task order at the time of the IPR. The Contractor shall prepare all presentation materials and provided to the COR 5 business days prior to the IPR. IPR dates and locations will be coordinated in advance by the designated Government Representative. The frequency of an IPR will be defined at the Task Order level.

Deliverables:

• IDIQ Program Management Plan

• Programmatic In-Process Reviews (PIPR)

1.4.1.1 Kick-Off Meeting (KOM)

The Contractor shall provide a KOM with all partners to establish a baseline of understanding after the contract award or as directed by the Contracting Officer (KO) at a location mutually agreed upon between the Contractor and the Government to be determined by the COR within ten (10) business days of contract start. Participants will include Program Manager (PM), Government Functional Manager (FM), Government Technical Lead, KO, COR, and other key Contractor personnel and Government staff. At the KOM, the Contractor shall present the details of its intended approach and approximated project schedule for review and approval by the COR. The KOM will serve to initiate discussion regarding strategic questions, refine goals, define success, and explore the biggest challenges and breakthrough opportunities for the Government. This will be the beginning of a dialogue between the Government and the Contractor to ensure successful execution of this contract by the Contractor. The Contractor shall draft and coordinate the agenda and all Briefing Materials with the PM and FM for the KOM and include, as a minimum, the following:

• Introduction of management and technical teams

• Presentation of management plans and reports, initial technical issues, resolutions, and mitigation strategies

• Establishment of common understanding of the contract

• Other relevant items may be introduced at the discretion of the Contractor and/or the

Government.

Deliverables:

• KOM Agenda

• KOM Briefing Materials

• KOM Action Item Lists

• KOM Minutes

1.4.1.2 Monthly Status Report (MSR)

The Contractor shall provide an MSR that includes by task, financial, performance, system availability, and schedule status. The MSR will include proposed changes to the schedule as detailed in the management plan as well as property accountability, technical accomplishments, issues and risks, and planned activities for the next reporting period. The MSR shall also include the status of all training and certifications of all Defense Cyber Work Force Management (DCWF) positions. Any issue requiring Government response or action shall be brought to the Government’s attention immediately upon identification, and status captured in monthly reports.

1.4.1.3 Transition

1.4.1.3.1 Contract Transition-In

This contract allows for a 90-day transition-in period. In the event the incumbent-Contractor is not awarded the AMP IDIQ contract, then the successor Contractor shall execute transition with the incumbent-Contractor. The Contractor shall conduct key engagements with the previous- Contractor, receive and review all materials provided by the previous-Contractor, and otherwise complete all necessary actions and engagements to accomplish a seamless and expeditious transition of all development, enhancement, production, and sustainment efforts for the AMP suite of tools and associated tasks identified in this PWS from the previous-Contractor.

1.4.1.3.2 Contract Transition-Out

Prior to contract expiration, or in the event of a different Contractor winning a follow-on contract, the incumbent Contractor shall provide at a minimum all materials and support necessary to accomplish a seamless and expeditious transition of the tasks identified in this PWS to the incoming Contractor. The Contractor shall include electronic copies of the following: all in-progress working files, Concept of Operation (CONOPS) procedures, and final phase out meeting with Government, incumbent, and the new Contractor. The Contractor shall support a formal contract closeout process, including the documenting of lessons learned throughout the life of the contract. All deliverables shall be provided Thirty (30) business days before the end of the contract period of performance.

Deliverables:

• Transition Plan

• In-Progress Working Files

• Concept of Operations (CONOPS) Procedures

• Lessons Learned

1.4.1.4 – Demonstration Support.

The Contractor may be required to conduct demonstrations of software releases of any type at AMP IPRs, AMP user group meetings (UGM), or other events at Scott AFB IL or the Contractor location. The Contractor shall conduct technical presentations or demonstrations to USTRANSCOM, other DoD commands, or other AMP users. The Contractor shall support presentations or demonstrations at other venues when required by the PM.

1.4.1.5 AMP Program Business Meeting.

The Contractor shall participate in weekly virtual conferences lasting 30 to 60 minutes to provide current status of all tasks and present roadblocks, risks and challenges to the government.

1.4.2 Task Area 2: Technical Support for Studies and Analyses The Contractor shall support planning and execution of analytical studies approved by the PM and coordinated with the FM involving the use of AMP software. The Contractor shall notify the PM and FM of any and all requests for analytic support. This support includes software modifications, analysis of study requirements and products, and temporary on-site support. The Contractor may be required to work with other model development Contractors to define upgrades and enhancements to AMP software and other models, and to coordinate release and testing schedules. The Contractor also shall modify AMP software and enhance the graphical user interfaces (GUI) and/or charts. In support of this requirement, the Contractor shall conduct integration and testing, and perform troubleshooting to repair or modify software problems identified during model execution.

1.4.3 Task Area 3: Requirements Management Support

The Contractor shall facilitate and support the administration of the AMP requirements management process. The Contractor shall manage the activities necessary to receive, verify, analyze, refine, and confirm requirements provided by the AMP PM or FM. The Contractor shall employ a government directed/approved automated requirements tracking tool (currently Jira) to maintain the traceability of all requirements from capability needs through design and test; document all changes to those requirements and record the rationale for those changes throughout the system lifecycle. Requirements traceability shall be confirmed at each technical review (e.g., IPRs, Test Readiness Reviews (TRR), Operational Readiness Reviews (ORR), Production Readiness Reviews (PRR), and Requirements Definition Document (RDD) reviews).

As requirements are entered into the automated tracking tool, the Contractor shall assess each requirement and provide the level of effort and impacts to program costs and program schedule.

The Contractor shall record these assessments in its automated requirements management tool.

The Contractor shall provide the Government (Program Management Office (PMO) and FM personnel) remote access to this tool. The Contractor shall employ this tool as a repository and to input, track, trace, and manage requirements, including Software Problem Reports (SPR). The Contractor shall document its internal requirements management process in a Requirements Management Plan (RMP) to be delivered in the Contractor format.

Deliverables:

• Requirements Management Plan

1.4.4 Task Area 4: Software Design and Development Support

The Contractor shall design and develop software to provide new capability for AMP. The Contractor shall define a software development approach appropriate for the computer software effort to be performed under this PWS. This approach shall be documented in a Software Development Plan (SDP) and followed for all computer software to be developed and/or maintained under this effort. The SDP shall define the ’Contractor’s proposed life cycle model and the processes used as a part of that model. In this context, the term “life cycle model” is as defined in ISO/IEC/IEEE Std. 15289-2017. The SDP shall describe the overall life cycle and shall include primary, supporting, and organizational processes based on the work content of this

PWS.

The SDP shall contain the information defined by ISO/IEC/IEEE Std. 15289-2017 and the Plans or Procedures in the Table of ISO/IEC/IEEE Std. 15289-2017. In all cases, the level of detail shall be sufficient to define all software development processes, activities, and tasks to be conducted. At a minimum, information provided must include specific standards, methods, tools, actions, strategies, and responsibilities associated with development and qualification.

In addition, the Contractor shall:

• Propose release content and schedules based upon Government requirements and priorities.

• Provide necessary models and simulations to support the Verification, Validation, and Authentication (VV&A) process.

• Provide software size (executable lines of code and function points), cost, and schedule estimates, and include justification and methodology used to derive the estimates.

The Contractor shall consider use of third-party products that may be innovative or new to AMP and could improve system performance. The Contractor shall provide its recommendations concerning use of third-party products to the Government. In particular, the Government’s goal is to encourage reuse of software and components, especially in cases where the Government has unlimited data rights.

The Contractor shall ensure that the AMP software is developed to be compatible with the current USTRANSCOM software configuration standards (e.g., United States Air Force (USAF) Standard Desktop Configuration (SDC), network, security, Internet browsers, as well as compliance with Cloud One / Platform One Party Bus and similar cloud environment requirements, as applicable).

Deliverable:

• Software Development Plan

1.4.4.1 Software Testing

To ensure all Government specifications for each requirement at each release are met, the Contractor shall employ a comprehensive Government-approved testing program to verify Government-approved requirements, software patches, fixes or maintenance releases, replacement of COTS software, and replacement of hardware.

The Contractor’s Test and Evaluation (T&E) processes shall complement the Government T&E processes to include the Government T&E Master Plan (TEMP). Activities shall include developing a master T&E strategy that shall be included in the SDP; determining testability of change requests (CR); producing test plans; tracing requirements through multiple documents to test procedures; supporting application certification efforts; performing test and operational readiness reviews and supporting production readiness reviews; supporting Government T&E observation of the Contractor’s T&E (e.g., Government Witness Testing (GWT)/Government Acceptance Testing (GAT)); documenting test results; objectively analyzing data; participating in weekly teleconferences with functional and program management representatives; conducting risk analyses; capturing T&E metrics; testing performance; supporting operational test events;

and improving T&E processes.

For each release (with the exception of an emergency release), the Contractor shall prepare a Software Test Description (STD) that describes the Contractor’s test methodology and traces requirements from contractual and/or requirements documentation through to test cases. This requirements trace shall be documented as a Requirements Traceability Matrix (RTM) and included within the STD. The Contractor shall create test cases for each requirement that shall provide detailed test instructions, any pre-conditions, or inputs, and expected results for each required functional capability or defect. These test cases shall be included in the STD. The STD also shall describe the Contractor’s approach to conduct regression testing on changes made to commercial off-the-shelf components and application software components. In addition, the Contractor shall provide documentation that records the status and results of the Contractor’s test efforts. The Contractor shall deliver a Software Test Report (STR) that details test results following completion of Software Integration Testing (SIT).

The Contractor shall meet all government specifications for each requirement at each release.

The PM will make the final decision concerning software acceptance. Deficiencies will be documented, prioritized, tracked, and may result in non-acceptance of the software release by the Government. The software shall be resubmitted for testing and only accepted by the Government once it passes government testing. Deficiencies are defined as the difference between the functional specifications stated by the Government and the capability provided in the software being delivered to the Government. This definition includes capability previously delivered to the Government that was not a part of the new functional specifications or code changed due to fixing problems with the software that the Government Backlog Grooming Group (BLG) authorized.

The Contractor shall be responsible for SIT. The Contractor shall support Government participation in test events. These events include GWT, GAT, and User Acceptance Testing (UAT) of the software to ensure it is validated and verified against the provided requirements or problem reports.

Test events are divided by three formal reviews: Test Readiness Review (TRR), Production Readiness Review (PRR), and Operational Readiness Review (ORR). The goals of these reviews are to confirm the readiness of the application and test infrastructure (e.g., test environment and documentation) to start each test event, to identify the proper exit criteria necessary to complete each test event and obtain Government approval to proceed toward the next milestone leading ultimately to software fielding. The Contractor shall prepare briefing slides for each TRR, PRR, and ORR and provide them for Government review before either TRR, PRR, or ORR occurs.

1.4.4.2 Software Release Process

The Contractor shall follow the software release process described in the Government AMP Configuration Management Plan (CMP). Using the processes described in the Government CMP, the program’s Backlog Grooming (BLG), co-chaired by the PM and FM, will determine the contents of each software release per the functional user’s priorities. Software releases are categorized into major, minor, maintenance, or emergency releases. Releases are classified as “major” if they include change(s) in the system architecture (e.g., introduction or elimination of a database, transition from client-based application to web-based access) or security posture.

Major releases also include new functionality and may contain fixes to software problem reports.

Releases are classified as “minor” if they include new functionality, but no changes to the system architecture or security posture. Minor releases also may contain fixes to software problem reports. Maintenance releases may contain fixes to software problem reports and needed enhancements. Emergency releases normally contain only fixes to software problem reports but may include new capability rushed to the field to support a high-priority requirement. The Contractor shall deliver software source code with each release.

Each release must undergo cyberSecurity review to determine the degree to which the changes incorporated into the software impact the security or hardware architectures of the system, or include the implementation of a new operating system, database, or interface. This review is accomplished once the Contractor submits software security scans (current scan tool is Fortify) for analysis. The frequency of the Contractor delivery of Fortify scans for analysis will be as described in the Deliverables Table that appears in the first task order placed on contract at the beginning of each fiscal year. Once all Category 1 faults are corrected and the USTRANSCOM Cyber-Security Branch accepts risks identified as Category 2 and 3 faults, the AMP Government engineer, supported by PEO-T security engineer, will submit the necessary documentation (normally a minor modification checklist) for Government approval. Other forms of review include requests for interim authority to test or completion of the reaccreditation process. The Contractor shall assist the Government in achieving software acceptance by accomplishing tasks described in Paragraph 1.4.7 Security Engineering and Cybersecurity Requirements. AMP currently is accredited under the DOD Risk Management Framework (RMF).

The Contractor shall update the Software User Manual to provide USTRANSCOM functional personnel appropriate guidance for system operation.

1.4.4.3 Data Governance

The Contractor shall conduct a technical review of changes to Input / Output data with each software release to ensure government agreed upon standards are met. Following successful completion of the technical review, the Contractor will present the changes to the government for approval of the metadata. Once approved, the metadata changes will be incorporated into metadata graphs (such as those produced by dbSchema).

A Data Schema Review (DSR) will be conducted after SIT testing and prior to TRR for all Major and Minor releases. The Contractor shall submit proposed changes to the input/output data schema for all tools in the release to the PM/FM for review and approval. Once approved, the data schema changes will be finalized in the GAT testing release.

1.4.5 Task Area 5: Software Maintenance

The Contractor shall provide software maintenance for AMP. The Contractor shall correct software defects that AMP users have identified and documented in CRs, and shall conduct unit, integration, regression, and security testing of these fixes. The Contractor shall maintain the data objects and run-time infrastructure and adapt to changes in the AMP component models to ensure federated runs are operational.

The Contractor shall ensure that the AMP software is designed to be compatible with USTRANSCOM software configuration standards (e.g., United States Air Force (USAF) Standard Desktop Configuration (SDC), network, security, Internet browsers, as well as compliance with Cloud One / Platform One Party Bus and similar cloud environment requirements, as applicable).

The Contractor shall:

• Facilitate and support the administration of the AMP problem reports management process.

• Propose release content and schedules based upon software maintenance priorities directed by the AMP BLG

• Provide software level of effort, cost, and schedule estimates, and include justification and methodology used to derive the estimates

• Upon request of the government, provide design documentation/Requirement Definition Documentation (RDD) for high level of effort maintenance CRs

• Upon request of the government, provide Training Manual

• Code, test, document, and support full integration of software and software releases in accordance with AMP BLG direction

• Include a list and brief description of software defects that will be fixed in a given release in the SVD associated with that release

• Provide CM, Quality Assurance (QA), and documentation for all AMP software to include any necessary updates to the Software User’s Manual and Algorithms Document.

1.4.6 Task Area 6: Application Administration

The Contractor shall provide on-site application administration and support to USTRANSCOM system administrators and functional users to support AMP desktop applications. This shall include model user training and the following activities:

• Plan, schedule, and support installation of AMP software, to include application patches and updates. Troubleshoot AMP installation problems. Support Functional Area Communications Computer System Manager installation of AMP application software on Non-Secure Internet Protocol Router Network (NIPRNET), Secure Internet Protocol Router Network (SIPRNET) clients, and Classified/Unclassified Research and Development Networks as necessary

• Support optimization, operation, troubleshooting, backup, recovery, modification, and upgrade of software.

• Debug AMP software

• Support testing of the application (e.g., USTRANSCOM Test Lab, support of GWT, GAT, and UAT)

• Provide technical support for hardware refresh efforts

• Provide Help Desk support to assist functional users to troubleshoot, debug, and correct

AMP problems

• Identify software modifications, provide support for analysis, work with other model development Contractors to define upgrades and enhancements to the AMP software

• Participate in technical discussions/exchanges to support modeling development; assist in articulating user requirements to primary developers

• Keep information located on the AMP SharePoint and/or IntelDocs site(s) current, including keeping the web pages updated with the latest downloadable AMP software releases, sample data, and AMP User Group materials

• Assist Government security and networking personnel to resolve application-related issues

The Contractor shall provide on-site application administration and support to USTRANSCOM system administrators and functional users to support AMP cloud applications This shall include model user training and the following activities:

• Support optimization, operation, troubleshooting, backup, recovery, modification, and upgrade of software.

• Debug AMP-TFA software (requires ability to debug AMP-Core software)

• Support testing of the application (e.g., USTRANSCOM Test Lab, support of GWT, GAT, and UAT)

• Provide Help Desk (functional/technical) support during Force Flow (FF) conferences and exercises, training and software testing, and code-level forensics to troubleshoot/debug issues within the model and help identify fixes to these issues within the AMP-TFA application

• Identify software modifications, provide support for analysis, work with other model development Contractors to define upgrades and enhancements to the AMP software, to include in the AMP-TFA application

• Support integration and testing of the AMP model, to include TFA

• Participate in technical discussions/exchanges to support modeling development; assist in articulating user requirements to primary developers

• Keep information located on the AMP SharePoint, IntelDocs, and/or Planset site(s) current, including keeping the web pages updated with the latest downloadable AMP software releases, sample data, and AMP User Group materials

• Assist Government security and networking personnel to resolve application-related issues

The Contractor shall keep the AMP Application Administration Manual updated. The contents of the manual shall include account administration; software installation; obtaining, generating, and updating reference files, shared drives, and web pages; troubleshooting and resolving operating system conflicts; maintaining logs; and creating reports.

1.4.7 Task Area 7: Security Engineering and CyberSecurity Requirements

1.4.7.1 Security Engineering Requirements

The Contractor shall evaluate all AMP software releases to ensure security issues are identified and addressed using the Defense Information System Agency (DISA) Application Security and Development Checklist and Security Technical Implementation Guide (STIG). The Contractor shall conduct code reviews and apply required security features for all AMP software.

The Contractor shall meet all Government specifications for design, development and implementation of secure applications and configurations through applying secure software development processes and secure coding practices with each Software Release Candidate.

The Contractor development efforts shall not utilize unsupported/extended support hardware, software, firmware, or computer code unless specifically agreed upon by the Government.

The Contractor software releases shall not introduce any unmitigated vulnerabilities unless specifically agreed upon by the Government. The Contractor shall analyze code scan results, remediate findings, provide rationale on false positives. Findings mitigated to a lower severity will be agreed upon by the Government.

1.4.7.1.1 Information Assurance Vulnerability Management

The Contractor shall monitor and analyze Information Assurance (IA) Vulnerability Management (IAVM) Notices, USTRANSCOM Security Notifications, United States Cyber Command (USCYBERCOM) and vendor security advisories and make recommendation to the Government for applicability to AMP.

The Contractor shall submit an initial analysis and assessment for high impact (risk) advisories (based on the STIG Finding Severity Category listed in the IA Vulnerability Advisories (IAVA), IA Vulnerability Bulletins (IAVB), and Technical Advisories) to the Government AMP PM, engineer, and security engineer. All STIG Finding Severity Category I and II IAVAs and IAVBs are considered high impact.

The Contractor shall prepare an analysis for other than high impact advisories and provide it to the USTRANSCOM AMP Engineer.

The Contractor shall provide a summary of security analysis and assessment results during weekly teleconferences and an update in the MSR.

1.4.7.1.2 IA Security Bulletins

The Contractor shall analyze applicable security bulletins to determine impact, identify mitigating factors, and develop recommendations to the Government regarding potential courses of action. Contractor recommendations shall be compliant with AMP, USTRANSCOM, and DoD security requirements and industry best practices. The Contractor shall develop and update mission criticality analyses, vulnerability assessments, risk assessments, and identification and counter measure implementations for Mission-Critical Functions.

The Contractor shall register with the DISA STIG library (https://cyber.mil/stigs/) upon contract award to receive notifications for updates to ensure the application and supporting application technology (i.e., operating system, database, servers, etc.) comply with the most up-to-date version of the DISA SRGs and STIGs. The Contractor shall evaluate each SRG/STIG item, determine applicability based on presence of technology/functionality, and annotate the checklist comment section for each item with statements of review status, applicability, and compliance/non-compliance. In the event of a non-compliant SRG/STIG check, the Contractor shall annotate open SRGs/STIG findings, along with fix or proposed mitigation actions, on a Plan of Action and Milestones (POA&M) for Government approval.

The Contractor shall protect unclassified DoD data from unauthorized access or disclosure in accordance with DoDI 8582.01, “Security of Unclassified Information on Non-DoD Information Systems,” DoDM 5200.01, Volume 4, and classified information under DoD 5220.22-M, National Industrial Security Program Operating Manual (NISPOM), and the USTRANSCOM Security Classification Guide.

1.4.7.1.3 Security Testing

The Contractor shall conduct an automated code scan of the desktop application using an approved code scan tool (currently Fortify) with the current rule packs, signatures, engines, etc.

installed. The Contractor shall comply with automated code scan requirements of the

Government selected Cloud Service Provider as part of the DevSecOps pipeline scan tools, such as Sonarqube, Twistlock, TruffleHog, etc. A qualified Contractor security engineer and programmer shall review the results of the automated code scan, determine, and mark false positives, and provide rationale for recommendations. The Contractor shall analyze and comment on respective analysis options (Not an Issue, Reliability Issue, Bad Practice, Suspicious, Exploitable, or custom). The Contractor shall provide the results and a detailed analysis 15 business days prior to software delivery.

For all software releases, the Contractor shall conduct software security testing in accordance with the DISA Application Security and Development Checklist and STIG and shall submit the completed checklist to the Government in accordance with Paragraph 1.6 Deliverables. As validation of continued compliance with the STIG, the Contractor shall submit application code scan reports for each software release as indicated in the deliverables table. Delivery shall coincide with the other programmatic documentation deliveries: 120 business days prior to program need-by date (required accreditation/authorization date) to support the DoD certification and accreditation methodology.

The Contractor shall run the applicable Enclave T&D and ASD STIGs against their environments and deliver results NLT 45 business days after the contract start date and NLT 45 business days after each DISA STIG/SRG update is released.

The Contractor shall ensure unsupported components are replaced/removed prior to end of life per a Government approved POA&M. The Government approved POA&M will outline the transition to supported components during any extended support period. The Contractor shall provide code scans with every release candidate. The scans shall include all application source code written for the application and Third-Party Libraries (TPL) that were modified for inclusion in the application. Non-functional (non-evoked) code within the TPLs will not be included in scan output. When scanned, source code will be in plain text format and encoded components (e.g., base64 images) will not be included.

The Contractor shall track all open findings on a Government reviewed and approved POA&M.

The Contractor shall establish a Burn Down Plan to prioritize remediation actions based on finding severity and Government discretion. The Contractor shall assist the Government Information System Security Manager with conducting an annual review of scan findings to ensure the POA&M and Burn Down Plan accurately reflect the current risk posture of the software. The Contractor will provide the results of the review to the Government.

1.4.7.1.4 Use of Automated Code Scanning Tool

The Contractor shall use an automated tool to scan the application source code to identify and remediate vulnerabilities or weaknesses in the application design/coding, such as those described in the Common Weakness Enumeration/System Administration, Networking, and Security Institute (CWE/SANS) TOP 25 Most Dangerous Programming Errors (http://www.sans.org/top25-programming-errors) and Open Web Application Security Project (OWASP) Top Ten (http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project), that could be exploited by unauthorized sources.

http://www/ http://www/

1.4.7.2 AMP Security Assessment and Authorization

1.4.7.2.1 Risk Management Framework (RMF)

The Contractor shall develop, configure, and/or operate information system components and/or information systems securely in accordance with the current versions of DOD policy, National Institute of Standards and Technology (NIST) Special Publications (SPs), National Security Agency (NSA) publications, Committee on National Security Systems (CNSS) issuances, and United States Cyber Command (USCYBERCOM)…