2023.06.15 AMP IDIQ PWS DRAFT v6.3.docx

Program Executive Office USTRANSCOM (PEO-T)

Performance Work Statement (PWS)

For

Analysis of Mobility Platform (AMP) Indefinite Delivery Indefinite Quantity (IDIQ) FY25 – FY29 Support

15 June 2023

UNCLASSIFIED

DRAFT Ver 6.3

UNCLASSIFIED

Table of Contents

UNCLASSIFIED

UNCLASSIFIED

1. Description of Services Background 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 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.

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 has served as the Department of Defense’s (DOD’s) model of record for OSD-level major mobility programmatic studies since 1995. AMP 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 core AMP discrete event simulation environment, resulting in capabilities to enable AMP 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 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, security requirements, or updates to Commercial Off the Shelf (COTS) products used by the system. Additionally, the 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, Functional Manager, Engineers, Security, end-users, and related technology partners.

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 Operational DevSecOps for ISR NexGen (ODIN) environment for Secret Internet Protocol Router Network (SIPR), and 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).

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 Program Manager (PM) 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.”

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

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 developers should 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: Task Order Management

(OPS/CAP)

This task area shall encompass overall contract management that tracks the performance of the work. The Contractor shall provide the planning, direction, coordination, and control necessary to accomplish all requirements in this PWS. The Contractor shall designate key personnel responsible for the cost, schedule, and technical performance for the contract and shall serve as a primary Point of Contact for both management and technical matters. In addition, the Contractor shall participate in In-Process Reviews (IPRs) where the status of the work and associated deliverables is reviewed with Government leadership. The Contractor shall prepare a Task Order Management Plan (TOMP) describing the technical approach, organizational resources, and management controls to be employed to meet requirements. The Contractor shall maintain an Integrated Master Schedule (IMS) to plan out new system capabilities, functionality changes, system maintenance, and/or product upgrades. The IMS shall include all planned releases for the following year at a minimum.

Deliverables:

Task Order Management Plan (TOMP) In-Process Reviews (IPR) Integrated Master Schedule (IMS) Kick-Off Meeting (KOM) The Contractor shall attend 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 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 resolve 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 coordinate the agenda for the KOM and include, as a minimum, the following:

· Introduction of management and technical teams

· Presentation of management plans and reports, 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 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 should also include the status of all training and certifications of all IAWIP 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) Contract Transition (OPTIONAL) This contract allows for a 90-day transition period as an optional task that may be exercised if required. Prior to contract expiration, or in the event of a different Contractor winning a follow-on contract, the 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 forty-five (45) 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 System for Award Management (SAM) The Contractor shall report in the System for Award Management (SAM): 1) the total dollar amount invoiced for services performed during the previous Government FY under the contract; 2) the Prime Contractor direct labor hours expended on the services performed during the previous Government FY; and 3) if applicable Tier 1 Subcontract number, including Unique Entity Identifier (UEI) and name, and the number of Subcontractor direct labor hours expended under the contract. Reporting inputs will be for the labor executed during the period of performance during each Government FY, which runs October 1 through September 30.

Data Protection Data (technical data and computer software) shall be protected IAW AMP Program Protection Plans (PPP), System Security Plans, and cyber security guidelines, Security Engineering and Cyber Security Requirements. The Government reserves the right to witness all contractor efforts to accomplish PWS requirements and maintains the right to comment on processes.

The contractor shall indemnify the Government from any liability to data owners or licensors resulting from, or as a consequence of, a release or disclosure of technical data and computer software made by this contractor or its officers, employees, agents, or representatives.

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.

For all non-commercial software provided by contractor, contractor shall ensure that any individual who creates any of the computer software provides an assignment of 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.

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.

Task Area 1 Subtask 6 - Demonstration Support.

The contractor may be required to conduct demonstrations of software releases of any type at Scott AFB IL during AMP IPRs or AMP user group meetings (UGM), or at the developer or subcontractor locations. 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.

Task Area 1 Subtask 7 – AMP Program Business Meeting.

The contractor shall participate in weekly telephone conferences lasting 30 to 60 minutes to provide current status of all tasks.

Task Area 2: Technical Support for Studies and Analyses (OPS) The contractor shall support planning and execution of analytical studies that involve the use of AMP software, and that could be conducted by USTRANSCOM, or other agencies as approved by the PM and coordinated with the FM. This shall require software modifications, analysis of study requirements and products, and on-site support. For specific studies, 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.

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 Functional Manager (FM). The contractor shall employ an automated requirements tracking tool 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 Task Area 4: Support for Design and Development 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 and any projected 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, Software Design Description 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; 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. In this contract, 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) 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, plan set, etc. for each tool within the AMP suite of tools to use in support of SIT. It is expected that each setup/plan set provided will run to completion prior to the completion of SIT. The FM will provide updates to the setups/plan set 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) 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 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 developer 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) 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/plan sets introduced to the testing process.

During UAT, the contractor shall record, and track deficiencies discovered by functional users participating in UAT and by contractor 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.

Deliverables:

· PRR and Briefing Slides 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 cyber security 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 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 Cyber Security 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:

· Software User Manual

· Code Scans

· Source Code

· Executable Programs 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).

Deliverables:

· Metadata Graphs Task Area 5: Software Maintenance (OPS) The contractor shall provide software maintenance for AMP. The contractor shall correct software defects that AMP users have identified and documented in Change Requests (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 developed to be compatible with the current and any projected 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 change requests

· 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 User Manual Task Area 6: Application Administration (OPS) The contractor shall provide on-site application administration and support to USTRANSCOM system administrators and functional users to support AMP desktop applications and AMP web 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 Secure Internet Protocol Router Network (SIPRNET) clients, as necessary

· Support optimization, operation, troubleshooting, backup, recovery, modification, and upgrade of software. Debug AMP software and 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 and correct AMP problems

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

Deliverables:

· Updated/Current Application Administration Manual Task Area 7: Security Engineering and Cyber Security Requirements (OPS) Task 7 Subtask 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.

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.

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

Security Testing The contractor shall conduct an automated code scan of the application using an approved code scan tool (currently Fortify) with the current rule packs, signatures, engines, etc. installed. A qualified developer 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 developer shall submit application code scan reports for each software release as indicated in the deliverables table.