Atch 2 20240212 AMP_PWS_TO01 - v1 FINAL.pdf

Attachment 2

HTC71124RD002

PERFORMANCE WORK STATEMENT

FOR

TASK ORDER (TO) 01

ANALYSIS OF MOBILITY PLATFORM (AMP)

12 Feb 2024

Table of Contents

1 DESCRIPTION OF SERVICES

1.1 Background

1.1.1 AMP Suite of Tools

1.1.2 AMP Analytic History

1.2 Objective

1.3 Scope

1.4 Performance Requirements

1.4.1 Task Area 1: Contract and Program Management

1.4.2 Task Area 2: Technical Support for Studies and Analysis

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

1.5 Deliverables

2 Service Delivery Summary (SDS)

3 Government-Furnished Property (GFP) and Government Furnished Information (GFI) . 63

3.1 Use of Government Furnished Computers

3.1.1 Privately Owned Computers

3.2 Information Services

3.2.1 Access to Government Services

3.2.2 Official Business

3.3 Facilities

3.3.1 Secure Communications – Secure Internet Protocol Router Network (SIPRNET) 65

4 General Information

4.1 Place of Performance

4.2 Travel

4.3 Hours of Operation and Federal Holiday

4.4 Other Direct Costs (ODC)

4.5 Account Management

4.6 Section 508 Accessibility

4.7 Period of Performance

4.8 Latent Defects

4.9 Quality Assurance

4.10 Acquisition Streamlining

5 Non-Disclosure Requirements

6 Security

6.1 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:

6.2 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 - AMP

1 DESCRIPTION OF SERVICES

1.1 Background

1.1.1 AMP Suite of Tools

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 the same strategic simulation algorithms as 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 air refueling (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

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

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 (CRs), security requirements, or updates to Commercial Off the Shelf (COTS) products used by the system. Additionally, Contractor shall provide production support to include troubleshooting and resolving user problems as well as identifying opportunities to improve the system. Overall, software development support shall include all aspects of the SDLC necessary to sustain and modify the system baseline. The Contractor shall work closely with other members of the team to include Government Program Manager (PM), Functional Manager (FM), Engineers, Security, end-users, and related technology partners.

1.3 Scope

This PWS contains requirements for AMP development for FY25-FY29 impacting the full suite of tools in areas including, but not limited to:

• Sustaining and enhancing AMP-TFA capabilities including its employment in unclassified and classified cloud environments

• Sustainment, development and release of new AMP-Core capabilities intended to improve the quality and delivery of Programmatic Analysis, Operational Applications, Optimization Capabilities and Seaport and Airport Analysis

• Sustaining and continuing ARM development efforts

• Adjustments and enhancements to the federation of the AMP-Core/TFA and AMP-PAT models.

• Sustainment, development and release of new RCAT capabilities

• Improvements to the AMP suites’ Contested Environment modeling capabilities

• Developing ARM, RCAT, AMP-PAT, JMCE, and AMP-Core to the Cloud environment to include modernizing shared network and data amongst the applications

• Transitioning/Supporting Research, Development, Testing, and Evaluation (RDT&E) efforts into the AMP Suite of tools 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.

While the requirement to host AMP-Core capabilities on a desktop platform is expected to endure indefinitely, the remaining desktop modules of AMP may also transition to Platform One Party Bus. The Contractor’s support shall include expertise with Platform One Party Bus, and the DAF Cloud CLOUDworks (formerly known as the Operational DevSecOps for ISR NexGen (ODIN)) environments for the Secret Internet Protocol Router Network (SIPR) and the Joint Worldwide Intelligence Communication System (JWICS).

The Contractor shall coordinate with the AMP PM and 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 this 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.”

All references, including electronic libraries, can be found in Appendix A to this PWS.

1.4 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 contractor 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).

The following tasks are included in the scope of this TO. .

• Task Area 1: Contract and Program Management

• Task Area 2: Technical Support for Studies and Analyses

• Task Area 3: Requirements Management

• Task Area 4: Support for Design and Development

• Task Area 5: Software Maintenance

• Task Area 6: Application Administration

• Task Area 7: Security Engineering and CyberSecurity Requirements

• Task Area 8: Support for Annual AMP Contingency Plan Review

• Task Area 9: Configuration Management

• Task Area 10: Sustainment Enhancements

• Task Area 11: New Capability

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 X 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 is defined in Table 1-3 Deliverables.

Deliverables:

• Task Order Management Plan (TOMP)

• In-Process Reviews (IPR)

• Integrated Master Schedule (IMS)

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 Cyberspace Workforce Qualification and Management Program 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.

Deliverable:

• Monthly Status Report (MSR)

1.4.1.3 Transition (Optional)

1.4.1.3.1 Contract Transition-In (Optional)

This contract includes a 60-day option period for transition-in. If exercised, this option period will provide up to 60 days to execute all transition activities with all Government identified stakeholders so as to assume responsibility of all development, enhancement, production, and sustainment tasks identified in this PWS on day one of contract performance. The Contractor shall schedule and conduct key engagements with all Government identified stakeholders so as to obtain all materials and information necessary to complete all actions and engagements to support a seamless transition as outlined in the Contractor’s Transition Plan incorporated into the contract by reference.

1.4.1.3.2 Contract Transition-Out (Optional)

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 Data Protection

1.4.1.4.1 Data (technical data and computer software) shall be protected IAW AMP Program

Protection Plans (PPP), System Security Plans, and cybersecurity guidelines, Security Engineering and CyberSecurity Requirements. The Government reserves the right to witness all the Contractor efforts to accomplish PWS requirements and maintains the right to comment on processes.

1.4.1.4.2 The Contractor shall indemnify the Government from any liability to data owners or licensors resulting from, or because of, the use of embedded open-source software or Commercial Off-the-Shelf (COTS) software, or failure to comply with the licenses and covenants associated therewith, and/or a release or disclosure of technical data and computer software made by this Contractor or its officers, employees, agents, or representatives.

1.4.1.4.3 All computer software and technical data developed under this contract shall be delivered with unlimited data rights, as defined in the Deliverables section of each Task Order (TO) PWS. In this context, technical data and computer software developed under this contract do not include embedded open-source software or Commercial Off-the-Shelf (COTS) software products. The Contractor must identify these products to the Government and obtain the respective licenses.

1.4.1.4.4 For all non-commercial software provided by Contractor, Contractor shall ensure that any individual who creates any of the computer software assigns to the Contractor any and all proprietary rights in the computer software including all copyrights and patent rights to the software so that the Government has the unlimited rights to the software specified above. It is the ’Contractor’s obligation to ensure compliance with all open source covenants or requirements if any open source software is included in any deliverable so that the Government has the required unlimited rights.

1.4.1.4.5 The Contractor shall comply with the requirements of the Contract Security Classification Specification DD Form 254 and the security requirements contained in this PWS to ensure proper safeguarding of classified material, events, and processes.

1.4.1.5 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.6 AMP Program Business Meeting

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 Analysis 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 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).

Deliverables:

• Software Development Plan

• Software Design Description

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 CRs; 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 developer’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.

Deliverables:

• TRR and Briefing Slides

• PRR and Briefing Slides

• ORR and Briefing Slides

• Software Test Description (with test cases and RTM)

• Software Test Report

• Software Version Description (SVD)

1.4.4.1.1 SIT and TRR

The Contractor shall lead and conduct Software Integration Testing (SIT) and provide a SIT Report to the Government upon completion. The FM shall provide the Contractor with model setups, planset, etc. for each tool within the AMP suite of tools to use in support of SIT. It is expected that each setup/planset provided will run to completion prior to the completion of SIT.

The FM will provide updates to the setups/planset with each release.

If the Contractor has used automated test scripts to verify software problem fixes for a software version entering a scheduled test event involving Government participation, the Contractor shall provide a user-readable version of the automated test script(s) and expected test result(s) for each test case; these shall be included in the STD. The Contractor shall provide the results of automated testing of the software build to be used at the start of scheduled test events, and any builds occurring during scheduled test events. The Contractor shall include these automated test result(s) as an addendum to the STR.

For maintenance releases, the Contractor shall conduct a regression test of the revised software to ensure the software changes do not degrade system operation. The Contractor shall brief results of the regression test during TRR.

Upon completion of SIT, the Contractor shall conduct a TRR and GWT/GAT commences.

Deliverables:

• TRR and Briefing Slides

• SIT Report

• User-readable version of automated test script(s)

1.4.4.1.2 GWT/GAT and ORR

The purpose of GWT is to verify developer test steps for each CR. The Government representative will observe the Contractor as they test each CR within the release.

GAT is conducted under the direction of the FM and primarily conducted within USTRANSCOM. During this test event, all CRs will be tested and retested in subsequent testing releases until all CRs have passed. Operational testing is also conducted during GAT; in this testing, analysts use the GAT release to mimic real world application of tools in the AMP program to ensure the program continues to be mission capable.

During GAT, the Contractor shall record, and track deficiencies discovered by functional users participating in GAT and the Contractor personnel but shall not issue a new version of software for continuation of GAT without PM approval. In accordance with PM and FM prioritization and PM direction, the Contractor shall resolve these deficiencies and present another software version for either GWT or GAT.

For maintenance releases, the Government (PM/FM) may request additional regression tests from the Contractor at the end GAT, based on the results of regression test presented at TRR. In such an event, the Contractor shall brief results of the additional regression tests during ORR.

Upon completion of GWT and GAT, the Contractor shall conduct an ORR. The purpose of the ORR is to review the results of GAT and GWT, and to determine the readiness of the software to undergo UAT. To support the ORR, the developer shall produce the test artifacts along with a description of any open SPRs for review by the PM and functional representatives. During ORR, the Contractor shall brief the results of GAT and GWT. The Contractor shall deliver all artifacts, including a draft Software Version Description (SVD), to the PM and place them under Configuration Management (CM) control. The successful outcome of this review should result in Government PM approval to proceed to UAT.

Deliverables:

• ORR and Briefing Slides

• Software Version Description (SVD)

1.4.4.1.3 UAT and PRR

UAT marks a final testing of each CR. There is no operational testing conducted, no new test cases introduced, and typically no additional setups/plansets introduced to the testing process.

During UAT, the Contractor shall record and track deficiencies discovered by functional users participating in UAT and by the Contractor’s personnel but shall not issue a new version of software for continuation of UAT without PM approval. Once the software is delivered to the Government for UAT, the Contractor shall not implement changes to the software baseline under test until the Government has completed (or postponed) testing, prioritized software, or test problem reports, and has accepted the change(s) proposed to resolve the problem(s). In accordance with PM and FM prioritization and PM direction, the Contractor shall resolve these deficiencies and present another software version for UAT.

For maintenance releases, the Government (PM/FM) may request additional regression tests from the Contractor at the end UAT, based on the results of regression test presented at ORR. In such an event, the Contractor shall brief results of the additional regression tests during PRR.

After completion of UAT, the Government will conduct a PRR, with developer participation, that demonstrates readiness of the application and infrastructure to support fielding to the production environment, and to issue a fielding decision.

• PRR and Briefing Slides

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 Government will establish the number of releases expected by type for each fiscal year in the first task order of each fiscal year. 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’s delivery of Fortify scans for analysis will be as described in Table 1-3 Deliverables. 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 1.4.7 Task Area 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.

Deliverables:

• Updated Software User Manual

• Code Scans

• Source Code

• Executable Programs

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.

Deliverables:

• Metadata Graphs

• DSR and Briefing Slides

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

1.4.5.1 Software Maintenance for AMP-Core, AMP-PAT, RCAT, JMCE, and AMP-TFA 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.

Deliverables:

• Requirements Definition Document (RDD)

• Training Manual

• Updated Algorithm Document

• Updated Software User Manual

1.4.5.2 Software Maintenance for ARM

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.

Deliverables:

• RDD

• Training Manual

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…