2025.04.14 Draft TRAC2ES PWS.docx

DOCX document 6 MB Posted

Attached to
TRANSCOM Medical Regulating and Command & Control Evacuation System (TRAC2ES)
Solicitation number
TRANSCOM25D012
Issued by

About this file

This document is a Draft Performance Work Statement (PWS) for the United States Transportation Command's (USTRANSCOM) Medical Regulating and Command & Control Evacuation System (TRAC2ES) software development support contract. The PWS seeks an agile software development contractor to provide comprehensive support for TRAC2ES, a system that manages Department of Defense global patient movement processes, with up to 8,000 concurrent users. The contract will require the contractor to perform tasks including software development, system maintenance, cybersecurity compliance, DevSecOps implementation, cloud migration, monitoring, production support, and training services.

The contract is structured for a base year (1 June 2026 - 31 May 2027) with four optional years, and will involve developing and maintaining software using agile methodologies, implementing security controls, performing static code analysis, managing system environments, and providing role-based training for users. Key technical requirements include using Java, implementing continuous integration/continuous deployment (CI/CD), maintaining microservices architecture, and ensuring compliance with Department of Defense security standards like Risk Management Framework (RMF), Security Technical Implementation Guides (STIGs), and Zero Trust principles. The contractor will be responsible for migrating the system to USTRANSCOM's DevSecOps ecosystem and maintaining high system availability with 99.3% uptime.

View the file

Other files

File Type Posted
2025.04.15 TRAC2ES_RFI.docx DOCX document

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Program Executive Office USTRANSCOM (PEO-T)

Performance Work Statement (PWS)

For

USTRANSCOM “Medical” Regulating and Command & Control Evacuation System (TRAC2ES)

11 April 2025

Contents

1 Description of Services1
1.1Background1
1.2Scope2
1.3References2
1.4Performance Requirements2
1.4.1Task Area 1: Task Order Management (BY-OY4)3
1.4.1.1Contractor Transition Phase-In (FY24)3
1.4.1.2Kick-Off Meeting (KOM)3
1.4.1.3Scrum Ceremonies and Weekly Updates4
1.4.1.4Monthly Status Report (MSR)4
1.4.1.5Contract Transition Phase-Out6
1.4.1.6System for Award Management (SAM)6
1.4.2Task Area 2: Software Development Support (BY-OY4)6
1.4.2.1Agile Software Development Support8
1.4.2.2Software Defect Support8
1.4.2.3Commercial of the Shelf (COTS) Support8
1.4.2.4Deployment Pipeline Support8
1.4.2.5Static Application Security Testing (SAST) Support9
1.4.2.6DOD Security Requirements Guides (SRGs) and Security Technical Implementation Guides (STIGs) Compliance Support9
1.4.2.7Identity, Access and Zero Trust9
1.4.3Task Area 3: Implement New Operational Capability (BY-OY4)10
1.4.3.1Design and Plan10
1.4.3.2Build and Deploy11
1.4.3.3Static Application Security Testing (SAST) Support11
1.4.4Task Area 4: Monitoring and Production Application Support (BY-OY4)11
1.4.4.1Monitoring Support12
1.4.4.2Production Support12
1.4.4.3Identity and Access12
1.4.4.4Production Support Analysis13
1.4.4.5System Data Analysis Support13
1.4.4.6Cybersecurity Analysis13
1.4.4.7Cybersecurity Service Provider (CSSP) Support13
1.4.4.8Interoperability Certification Support14
1.4.4.9Platform/Infrastructure Support14
1.4.4.10Commercial Off The Shelf (COTS) Support14
1.4.4.11Training Services14
1.4.5Task Area 5: Risk Management Framework (RMF) Support (BY-OY4)17
1.4.5.1Cybersecurity Planning Support18
1.4.6Task Area 6: DevSecOps Ecosystem (DSOE) Support18
1.4.6.1Design Cloud DevSecOps Migration Architecture19
1.4.6.2Develop Application DevSecOps Migration Strategy19
1.4.6.3Build DevSecOps Enclave Environments20
1.4.6.4Automation Support20
1.4.6.5Cutover Support21
1.4.6.6Lessons Learned21
1.5Delivery Schedule21
1.5.1Warranty25
1.5.2Inspection25
1.5.3Final Acceptance25
2 Performance Standards25
2.1Net Ready – Key Performance Parameters (NR-KPP)26
2.2Availability26
2.3Production Support27
3 Government Furnished Equipment (GFE), Government Provided Software (GPS), and Government Furnished Information (GFI)27
3.1Use of Government-Furnished Computers.27
3.1.1Privately Owned Computers28
3.1.2Information Services28
3.1.3Access to Government Services28
3.2Official Business28
3.3Government Furnished Information (GFI)29
3.4Secret Internet Protocol Router Network (SIPRNET)29
3.5Property Accountability29
4 General Information29
4.1Place of Performance29
4.2Account Management30
4.3Section 508 Accessibility30
4.3.1Technical Standards30
4.3.2Functional Performance Criteria30
4.4Travel and Other Direct Costs (ODC Priced-Separately)30
4.4.1Travel30
4.4.2Other Direct Costs Requirements31
4.4.3Management/Acquisition of 3rd Party Licenses31
4.5Period of Performance33
4.6Specialized Skills Required33
4.7Velocity33
4.8Latent Defects34
4.9Identification of Security and Non-Disclosure Requirements34
4.10Quality Assurance34
4.11Standards34
5 Security35
5.1Cybersecurity for (Non-TSP Contracts– Operationally Critical Support)35
5.1.1Operationally Critical Support35
5.1.2Cybersecurity Incident Reporting35
5.1.3Cybersecurity Incident Reporting Timelines35
5.1Mandatory Reporting Data35
5.1.5Incident Reporting Coordination36
5.1.6Confidentiality and Non-Attribution Statement37
5.1.7Subcontracts37
6 Security (Physical, Personnel, Information, Industrial, Antiterrorism/Force Protection, and Operations (OPSEC))37
6.1Operations Security (OPSEC)37
6.2General Security Information38
6.3Citizenship and Clearance Requirements38
6.4Information Systems (IS) Roles/Categories and Associated Suitability Requirements (Federal Investigative Standards)38
6.5Security Clearance and Special Access Requirements39
6.6Facilities Clearance (FCL)39
6.7Personnel and Facilities Clearance Validation39
7 MEASURES TO PREVENT UNAUTHORIZED DISCLOSURE OF CRITICAL INFORMATION39
7.1Common Access Card Issuance Procedures40
7.2Access to Scott Air Force Base or USTRANSCOM Facilities41
7.3Visits by Non-Assigned Contractors to USTRANSCOM/SDDC Buildings41
7.4Visits by Permanently Assigned Contractors42
7.5Supplemental Notes Regarding Visit Information in Defense Information System for Security (DISS)42
7.6Security and Emergency Operations Training42
7.7Additional Security Conditions42
7.8Derogatory Information43
7.9Accessing NATO Information43
7.10Security Debriefing43
7.11Antiterrorism/Force Protection44
7.12Note to the Prime Contractor Facility Security Officer (FSO):44
7.13USTRANSCOM – Cyberspace Workforce Management44
7.14Foundational Qualification Requirements45
7.15Residential Qualification Requirements45
7.16IT Privileged User45
7.17USTRANSCOM-Required Training45
Appendix A: References46
Appendix B: List of Government Furnished Information53
Appendix C: Acronyms54
Appendix D: DoD Cyber Workforce Framework (DCWF) Code Assignments57

UNCLASSIFIED

UNCLASSIFIED

Description of Services

1.1 Background

The United States Transportation Command (USTRANSCOM) provides global air, land, and sea transportation for the Department of Defense (DoD), both in times of peace and war through its Transportation Component Commands (TCCs): Air Mobility Command (AMC); Surface Deployment and Distribution Command (SDDC); and Military Sealift Command (MSC). USTRANSCOM provides synchronized transportation, distribution, and maintenance. Additionally, USTRANSCOM projects and maintains national power with the highest efficiency, the greatest speed and agility, and the most reliable level of trust and accuracy.

DoD Instruction (DoDI) 6000.11, Patient Movement, assigns the Commander of USTRANSCOM as the single manager for global patient movement and directs USTRANSCOM to develop and implement integrated patient movement regulation and evacuation processes. The Joint Publication (JP) 4-02 provides the doctrinal foundation for the patient movement system and clarifies DoD policy for patient movement of contaminated, contagious, or potentially exposed casualties. Supplemental guidance, USTRANSCOM Instruction (USTCI) 4200.03, Patient Movement of Contaminated, Contagious of Potentially Exposed Casualties and USTCI 4200.04 (Basic thru Vol 13) Policy for Global Patient Movement Operations further assigns theatre patient movement requirements center processes and responsibilities to the USTRANSCOM Surgeon General (TCSG) and clarifies USTRANSCOM policy for patient movement of contaminated, contagious, or potentially exposed casualties.

The TRANSCOM “Medical” Regulating and Command & Control Evacuation System (TRAC2ES) combines relevant doctrine, policies, processes, and procedures along with an automated decision support system to manage the DoD global patient movement process. TRAC2ES provides for patient movement monitoring, forecasting, and planning to support both fixed and deployable operations and includes medical regulating and patient evacuation. TRAC2ES provides In-Transit Visibility (ITV) and command & control decision support. TRAC2ES supports the Assistant Secretary of Defense for Health Affairs (ASD(HA)), the Joint Staff, Combatant Commanders, and USTRANSCOM during war, peace, contingencies, and operations other than war.

The objective of this requirement is to provide software development support and expertise for TRAC2ES. 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 Product Owners, engineers, security, and end-users.

1.2 Scope

The Contractor shall provide agile software development support for TRAC2ES, which has up to 8K users at any given time. 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 the Contractor shall utilize the most current available USTRANSCOM Enterprise approved tools for achieving DevSecOps and maximize cloud services. The Contractor shall provide system functionality while reducing and/or eliminating dependency on individually licensed Commercial Off The Shelf (COTS) products. This support shall include expertise with Java. The Contractor shall provide support in achieving the discipline of DevSecOps. This support shall include expertise with Continuous Integration/Continuous Deployment (CI/CD) and the use of software build pipelines.

Further, the Contractor shall provide expertise to build and maintain the TRAC2ES development, non-production, exercise, training and production environments in the USTRANSCOM Unclassified and Classified Government Cloud (TC-UGC and TC-CGC).

1.3 References

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

1.4 Performance Requirements

The Contractor shall use a Government owned Application Lifecycle Management (ALM) tool (e.g. Jira) to effectively manage and execute the Agile Scrum methodology 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 Story Points and establish a waterline, 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 predicable velocity, the developers should complete the artifacts they commit to in each software sprint, and team members are encouraged to collaborate towards requirements completion. User stories and design documentation shall be maintained within the government provided 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 in via the Government provided ALM tool. Each assigned requirement will have one or more associated artifacts.

The software development sprints are defined by the Government, are planned as no longer than four (4) weeks in length; and result in software releases. The software development sprint length shall be mutually agreed upon. Sprints may be a minimum of one (1) week but shall not exceed four (4) weeks in length, and result in releasable product.

1.4.1 Task Area 1: Task Order Management (BY-OY4)

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 Program Management Reviews where the status of the work and associated deliverables is reviewed in the context of the business processes supported by the system.

Deliverables:

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.

Product Roadmap. The Contractor shall maintain a product roadmap to plan out new system capabilities, functionality changes, system maintenance, and/or product upgrades. The product roadmap shall include current sprint, sprint+1, and sprint+2 at a minimum. The Contractor shall collaborate with the Government Product Owner to obtain the Government’s priority on software features and product updates.

1.4.1.1 Contractor Transition Phase-In (FY24)

This transition period will provide forty-five (45) business 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 will 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. The phase-in tasks shall be conducted during the transition period.

During this period, the incoming contractor will be provided transitional training, to include TC-UGC, TC-CGC and TRAC2ES application training, and work side-by-side with or shadow the outgoing contractor on processes and procedures for performance of day-to-day duties, and specific deliverables. This effort is to familiarize the incoming contractor with the USTRANSCOM work environment as it relates to the requirements of the PWS. This period is also for obtaining access to the software development tools, program tools, and development plans and procedures. The contractor shall be authorized access to Government facilities at Scott Air Force Base (SAFB) if necessary to provide contractor personnel familiarization with existing equipment, reporting, scheduling, and procedures. Many of the phase-in period tasks will be conducted over the Microsoft TEAMS application. The contractor shall provide representation from all contract task areas for this period. At the end of the transition period, the contractor shall assume responsibility for all PWS tasks.

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

1.4.1.3 Scrum Ceremonies and Weekly Updates

The Contractor shall provide a detailed approach on how the Scrum teams will satisfy the requirements. The Contractor shall provide Scrum Master(s) to lead the scrum team(s), and conduct scrum ceremonies (i.e. Sprint Planning, Daily Stand-ups, Sprint Reviews, and Sprint Retrospectives). Additionally, the Contractor shall conduct Weekly Update Meetings to (1) provide status on current development efforts and discuss any blockers or impediments, (2) schedule early looks or demos to aid developers throughout development as needed, (3) provide status on getting the Sprint +1 user stories and acceptance criteria to meet Definition of Ready, (4) Help Desk issues, and (5) Administrative updates such as upcoming calendar events, etc. The Contractor shall provide presentation material in a format compatible with Microsoft Office.

· Sprint Retrospective Output. The contractor shall provide the list of improvements team members have agreed to achieve in the upcoming sprints.

· Weekly Update Meeting Agenda and Meeting Minutes. The Contractor shall provide the status on current development sprints, the status on planning and preparations for the next development sprints, the status on production support issues, and administrative items.

1.4.1.4 Monthly Status Report (MSR)

The Contractor shall provide an MSR that includes by task the 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. Any issue requiring Government response or action shall be brought to the Government’s attention immediately upon identification, and status captured in monthly reports.

This report will contain the calls, artifacts received and the actions taken during the reporting period. It shall correlate actions taken to other tasks or solutions that address resolving the reason for the artifact. Since the artifacts are assigned via the Government ALM tool, and the Contractor will enter results into the Government ALM tool, metrics associated with the responsiveness, quantity, and duration of the artifacts will be extracted directly from the Government ALM tool. The status report shall include a cumulative tally of all artifacts assigned to the most recently completed release that have not been previously reported. This tally shall include the release identifier, total number of artifacts assigned to a release per category, the category (e.g. established within the ALM tool such as Requirement, Change Request (CR), Defect), and a total sum of total artifacts across all categories. Further, the report shall contain a sum of artifacts (per category and overall total) that were planned for each sprint (i.e. above the waterline after sprint planning using story points), as well as the sum of artifacts that are accepted in UAT (per category and overall total) and placed into production with the scheduled release. The bottom of the table shall include totals for each column. A notional example is provided below:

Table 1 – Notional Example

Waterline
Deployed
Release
CR
Defect
Requirement
Total
CR
Defect
Requirement
Total
10.3
17
4
9
30
17
5
7
29

10.3.1

10.4
22
9
4
35
22
9
4
35
Totals
39
16
13
68
39
17
11
67

Deliverable:

Monthly Status Report (MSR)

· The MSR format will be agreed upon by the Contracting Officer Representative (COR) and the Contractor and shall contain, but not limited to, the following information:

· Activities conducted and results

· Personnel by name and labor categories

· Identify any staffing changes

· Privilege Users DCWF information (required training completion date and DCWF expiration)

· Meetings attended IAW para 2.2.7 with a summary of relevant items discussed

· Proposed activities

· Open issues

· Actual and projected cost expenditures (Travel and ODCs)

· System availability and outages in cutover phase

· Time to Restore Services IAW Section 3

· Deliverable Status (including schedule changes)

· Summary of Incident Report(s) and associated AAR#s

· Change Failure Rate IAW Section 3

· Security Posture

· Artifact Status

· POAM Status (Overall, tracking to meet projected Estimated Completion Date, recommendation for reprioritization

· STIG status (Schedule, last completed vs most recent update), updated burn down

1.4.1.5 Contract Transition Phase-Out

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

1.4.1.6 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 fiscal year under the contract; 2) the prime contractor direct labor hours expended on the services performed during the previous Government fiscal year; and 3) if applicable Tier 1 subcontract number, including DUNS number/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 fiscal year (FY), which runs October 1 through September 30.

1.4.2 Task Area 2: Software Development Support (BY-OY4)

This task includes responding to requirements that are generated by the Government through change requests, program, security, production support, or trouble reporting mechanisms. ALM artifacts are the method for identifying software changes, which will be deployed into the Production environment. The Contractor shall properly record user stories, associated acceptance criteria, issues, and software solutions to create a knowledge base within the Government’s ALM tool. The Contractor shall use the Agile Scrum Framework; along with extreme programming practices such as test-driven development, refactoring, and continuous integration; when completing artifacts to include requirements elicitation and decomposition, completion of user stories and specifications, software development, security code scans, unit testing, integration testing, and UAT. The Contractor shall use a microservices architecture for new code and decouple monolithic legacy code when appropriate (e.g. failure isolation, multiple rates of change, simplify external dependencies, etc.) for long-term usability and scalability of the application. Additionally, the Contractor shall automate testing, security updates, configuration management, the software build process, etc. necessary to achieve Continuous Integration/Continuous Delivery (CI/CD).

Deliverables:

· Software. The primary deliverable of this task is software code, system configurations, database schemas, etc. resulting from this task. All software code, system configurations, database schemas, etc. associated with this contract shall be the property of the Government and shall not contain any company proprietary markings, logos, or any distribution restrictions. Software code shall be installed on the Government’s Staging and Production servers and provided as a tagged code segment via the Government managed code repository and/or delivered on other mutually agreed upon format.

· Release Documentation. As a minimum, this shall include a work plan with recurring updates, static code scans (e.g. Fortify scans), release test plan with results, UAT plan with test scripts, and Configuration Management Requests (i.e. release notes), which include all artifacts with associated descriptions and solutions, and deployment instructions.

· Updated Project Documents. Documentation sufficient to install, operate, and maintain the system shall be provided and maintained. These documents shall include updates to the product roadmap, COTS products, training manuals, user manuals, system installation procedures, and any supporting documents necessary for the Government to sustain the system.

· Overview

· Patient Movement Clerk

· Transport Crew Member and Secondary Roles

· TPMRC User

· Report User

· The contractor will provide an up-to-date, standalone User Guide for the business intelligence analytics tool that is used for system data analytics. This end user, step-by-step guide will include, but not limited to the following chapters:

· Overview

· Basic Queries

· Table Reports

· Chart Reports

· Dashboards

· Examples

· Updated System Documents, Security Documents, White Papers. All solution changes shall be documented as user stories, technical specifications and/or diagrams, interface control documents, system configuration documents, and/or Department of Defense Architecture Framework (DODAF) architectural artifacts. Additionally, documentation will be generated and maintained to support Static Code Analysis, the Risk Management Framework (RMF), Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs), DODI 8530.01, and the DOD Cloud Computing Security Requirements Guide.

1.4.2.1 Agile Software Development Support

The Contractor shall respond to ALM artifacts to change the system, as prioritized and assigned by the Government Product Owner. The Contractor shall participate in and/or lead the Scrum process and other meetings to define, build, test, document, and deploy updates to the system baseline. The Contractor shall ensure ample lead-time for understanding and responding to unique change requests. The planning for requested functionality may include the Contractor’s recommendations to minimize rework and cost. If a change is beyond the Contractor’s capacity to complete within one sprint, the Contractor shall decompose the Epic and/or Features into smaller user stories; and update the schedule (i.e. product roadmap). Complex tasks may require additional planning before coding. These tasks are assigned to a sprint for development of a specification prior to the implementation sprint. The Contractor shall work with subject matter experts to create, and receive approval on, user stories and associated acceptance criteria, functional specifications and/or technical specifications. The Contractor shall support UAT for releases to ensure proposed changes are acceptable to users; and, when required, host release reviews for functional users to illustrate system changes. The Contractor shall assist with Configuration Management Requests (i.e. release notes); and shall provide necessary support to maintain and document the security posture of the application as required by the RMF or applicable DOD accreditation process.

1.4.2.2 Software Defect Support

The Contractor shall immediately respond to escalated production support issues that cause work stoppage or operational problems with the system and ensure the Production system operates without interruption to functional users. Software defects that result in a work stoppage or impact to business operations shall result in an unplanned software Hot Fix. Correcting defects identified through production support that do not result in a work stoppage shall be prioritized and assigned to current sprint or a future sprint by the Government depending on the impact to business operations. The Contractor shall assist the production support activity in identifying the root cause of production support malfunctions and creating ALM artifacts (i.e. software code changes) to permanently resolve or prevent them. The Contractor shall input all actions taken to resolve artifacts into the Government ALM tool. The Contractor shall coordinate with production support to ensure minimal rework and downtime during software changes, and to ensure the production support activity understands planned system changes.

1.4.2.3 Commercial of the Shelf (COTS) Support

The Contractor shall provide support services for changes in COTS products to include patches (e.g. application, operating system, database), upgrades, and/or migration to newer technologies. This will involve analyzing the system for incompatibilities and deprecated features. Once prioritized by the Government, the Contractor shall refactor the necessary code to ensure continued system stability. The refactoring shall be assigned to sprint(s) and follow the Agile SDLC process for integration and testing of refactored code.

1.4.2.4 Deployment Pipeline Support

Once TRAC2ES is migrated and operational in the TRANSCOM Unclassified and Classified Government Cloud (TC-UGC and TC-CGC), the Contractor shall provide the expertise required to operate and maintain the Development, Non-Production, Exercise, Training and Production environments to reliably and efficiently compile, build, and deploy code. This shall include maintaining virtual machines and components, such as servers, memory, firewalls, load balancers, and storage (i.e. databases). Additionally, the Contractor shall maintain and update the Ports, Protocols, and Services (PPS) information. This shall include ports for internal and external traffic as well as the source and destination IP Addresses information. Air Force Department of Defense (AF-DOD) approved PPS worksheet will be used; available on the PPS Management at http://intelshare.intelink.gov/sites/ppsm.

1.4.2.5 Static Application Security Testing (SAST) Support

The Contractor shall run static code scans using a Government-approved code scan tools (e.g. Micro Focus Fortify) to mitigate potential of security vulnerabilities from being deployed into the production environment. Scans will utilize current scan engine and rule pack as determined by release candidate delivery date. If the software code has been redeveloped or refactored (changing the source code without modifying the external functional behavior), new scans must be provided to the Government by the Contractor.

The contractor shall provide code scans with every release candidate. The scans will include all application source code written for the application and Third-Party Libraries (TPL) that were modified for inclusion in the application. Non-functional (non-evoked) code within the TPLs will not be included in scan output. When scanned, source code will be in plain text format and encoded components (e.g., base64 images) will not be included.

1.4.2.6 DOD Security Requirements Guides (SRGs) and Security Technical Implementation Guides (STIGs) Compliance Support The contractor shall run the applicable Enclave T&D and ASD STIGs against their environments and deliver results NLT 60 days after the contract start date and NLT 60 days after each DISA STIG/SRG update is released. The Contractor shall register with the DISA STIG library https://cyber.mil/stigs/ to receive notifications for updates to ensure the application and supporting application technology (i.e. operating system, database, servers, etc.) complies with the most up-to-date version of the DOD SRGs and Application Security and Development STIGs. The Contractor shall evaluate each SRG/STIG item, determine applicability based on presence of technology/functionality, and annotate the checklist comment section for each item with statements of review status, applicability, and compliance/non-compliance. In the event of a non- compliant SRG/STIG check, the contractor will annotate enter open SRGs/STIG findings, along with fix or proposed mitigation actions, risk assessment, on a Plan of Action and Milestones (POA&M) with corresponding ticket in ALM tool for Government approval. The Contractor shall remediate any non-compliant checklist items.

1.4.2.7 Identity, Access and Zero Trust

The contractor shall be responsible for implementing a Zero Trust compliant Identity, Credential and Access Management (ICAM) solution that complies with all DoD regulations including: Identity, Credential, and Access Management (ICAM) Strategy, EO 14028, NIST SP 800-207, and the DoD Zero Trust Reference Architecture.

The contractor shall manage data and system resources in-line with Zero Trust principles, ensuring that systems and data resources are sufficiently segmented to facilitate the application of the defined identity and access control policy. The Contractor shall ensure that all communications and resulting transactions that take place among the components that make up TRAC2ES are individually authenticated and authorized according to attributes associated with the TRAC2ES Performance Work Statement the requesting process and the object being requested. All data ingested into TRAC2ES shall be validated for correctness and tagging with attributes that control access to it.

1.4.3 Task Area 3: Implement New Operational Capability (BY-OY4) The Contractor shall respond to ALM artifacts (i.e. new requirements) to implement new capabilities in the system (i.e. different than implementing change requests to existing capabilities). New capabilities will focus on creating new/additional system operational activities. This task shall include all Agile SDLC activities to support implementing new capabilities. The Contractor shall properly record user stories, associated acceptance criteria, issues, and software solutions to create a knowledge base within the Government’s ALM tool. The Contractor shall use the Scrum framework, extreme programming engineering practices, and a microservices architecture when completing artifacts to include requirements elicitation and decomposition, completion of user stories and specifications, software development, unit testing, integration testing, and UAT.

Deliverables:

· Software. The primary deliverable of this task is software code, system configurations, database schemas, etc. resulting from this task. All software code, system configurations, database schemas, etc. associated with this contract shall be the property of the Government and shall not contain any company proprietary markings, logos, or any distribution restrictions. Software code shall be installed on the Government’s Staging and Production servers and provided as a tagged code segment via the Government managed code repository and/or delivered on other mutually agreed upon format.

· Release Documentation. As a minimum, this shall include a work plan with recurring updates, static code scans (e.g. Fortify scans), release test plan with results, UAT plan with test scripts, and Configuration Management Requests (i.e. release notes) which include all artifacts with associated descriptions and solutions, and deployment instructions.

· Updated Project Documents. Documentation sufficient to install, operate, and maintain the system shall be provided and maintained. These documents shall include updates to the product roadmap, COTS products, training manuals, user manuals, system installation procedures, and any supporting documents necessary for the Government to sustain the system.

· Updated System Documents, Security Documents, White Papers. All solution changes shall be documented as user stories, technical specifications and/or diagrams, interface control documents, system configuration documents, and/or DODAF architectural artifacts. Additionally, documentation will be generated and maintained to support Static Code Analysis, the RMF, DISA STIGs, DODI 8530.01, DOD 8140.01-M (Defense Cyber Workforce Program), and the DOD Cloud Computing Security Requirements Guide.

1.4.3.1 Design and Plan

The Contractor shall provide a project plan, and once directed by the Government employ the Scrum process to design the necessary capability. This design shall include all necessary artifacts, with appropriate sizing/complexity documented in the Government ALM, required for planning, development, and testing. The project plan shall include logical milestones (i.e. Epics/Features) for the deployment, which will result in a Minimal Viable Product (MVP), as well as additional functionality and/or enhancements.

1.4.3.2 Build and Deploy

The Contractor shall employ the Scrum process and extreme programming engineering practices to define, build, test, document, and deploy updates to the system using a microservices architecture. This process agility shall support system change frequency for each defined sprint cycle. Each new capability plan shall include checkpoints for milestones to include acceptance for design, build, test, and deploy. Checkpoints are inherent in the Agile development process; however, it is extremely important that new capability software components be uniquely identified during the process. User stories (i.e. functional specifications) shall capture features to be deployed and will be used by the Government as a basis for testing and acceptance.

1.4.3.3 Static Application Security Testing (SAST) Support

The Contractor shall run static code scans using a Government-approved code scan tools to mitigate potential of security vulnerabilities from being deployed into the production environment. Scans will utilize current scan engine and rule pack as determined by release candidate delivery date. If the software code has been redeveloped or refactored (changing the source code without modifying the external functional behavior), new scans must be provided to the Government by the Contractor.

The contractor shall provide code scans with every release candidate. The scans will include all application source code written for the application and Third-Party Libraries (TPL) that were modified for inclusion in the application. Non-functional (non-evoked) code within the TPLs will not be included in scan output. When scanned, source code will be in plain text format and encoded components (e.g., base64 images) will not be included.

1.4.4 Task Area 4: Monitoring and Production Application Support (BY-OY4) This task includes monitoring and troubleshooting production applications; and responding to incidents that are generated by system users. Production support tickets shall be generated within the Government ALM tool. Production support tickets are the method for tracking and resolving incidents (i.e. specific issues), as well as processing user account requests. Incidents may involve generating software defect artifacts (i.e. for systemic problems requiring code changes); which will be prioritized by the Government. The Contractor shall document incidents and systemic problems for accurate reporting, metrics, and to provide a knowledge base within the Government ALM tool. The Contractor shall be responsible for ensuring the description and resolution for incidents they resolve are documented clearly.

Deliverables:

· System Performance Report. This report shall contain all open tickets listed in order of priority starting with highest priority and further sorted such that the earliest ticket of a given priority is at the top for that priority grouping. This report shall contain the ticket #, priority, associated tickets, descriptions, corrective action, date opened and closed with the user, as well as trend and other pertinent data. It shall correlate actions taken to other tasks or solutions that resolved similar tickets. If the Contractor has detected a trend, this report shall include a brief summary of the trend, associated tickets, pertinent distribution of causes, and recommended corrective action to prevent similar troubles. The Contractor shall use their expertise to recommend changes to software code, queries, data validations, etc. The Government will review these recommendations and provide guidance when appropriate. Since the production support tickets are managed via the Government ALM tool, metrics associated with responsiveness, quantity, and duration of tickets shall be extracted directly from the ALM tool and summarized in the report.

· Cyber Intrusion Incident Report. This report shall provide details identifying the root cause, impacts, and actions taken to resolve and prevent the vulnerabilities. The Initial Cyber Intrusion Incident Report is due within four (4) hours of the event. The Cyber Intrusion Incident Report Update is due within twenty-four (24) hours of the event.

1.4.4.1 Monitoring Support

The Contractor shall monitor current health, performance statistics, recent errors, full logs, and key metrics. The Contractor shall ensure the system is working normally; and report and resolve any breaches, security attacks, or anomalies in activity. The Contractor shall use log collection, monitoring, and analysis to understand the relationship between network, infrastructure, servers, application framework, and user behavior to gain a comprehensive view across all activity, across all sources, servers, and locations. In the event of a Cyber incident or intrusion, the contractor shall conform to the policy outlined in the TRAC2ES Incident Response Plan. The Contractor shall report any detected cyber intrusions. Cyber incidents shall be documented in a Cyber Intrusion Incident Report. The incident report shall document and report loss/compromise, suspected compromise, suspicious contact, or activity involving systems accredited to process classified information. It may be used as a preliminary response to supplement national reporting requirements and provide a resource to document initial or first response to a Cyber incident.

1.4.4.2 Production Support

The Contractor shall respond to and resolve operational problems with the system. This task includes responding to incidents, analyzing and correcting specific incidents, creating software development artifacts for systemic problems requiring code changes, and following escalated tickets to resolution. Typical incidents to be resolved under this task include database updates for specific records with incorrect data, which involves determining the cause of the issue, correcting the database, and determining whether a permanent code fix is necessary.

1.4.4.3 Identity and Access

The Contractor shall manage identities within their provided ICAM solution. The identity management solution should maintain a record for each user with sufficient detail to enable a comprehensive set of granular permissions for each user as well as via group permissions. When applicable, the solution will also ingest/inherit identity attributes from external systems (e.g., DISA’s Global Federated User Domain). The Contractor shall ensure this solution is in use for all components of (Program Name), whether they are accessed via applicable cloud environments, on datacenter infrastructure, or locally on end-user devices. The Contractor shall provide delegated authorities with the ability to request user accounts and specify attributes about those users to ensure they are only able to access TRAC2ES according to their job requirements in line with Zero Trust principles.

The Contractor shall manage access to TRAC2ES by integrating their ICAM solution with all components of the system. Multifactor authentication shall be used in all possible scenarios, and leverage DoD credentials (e.g., Common Access Card (CAC), YubiKey, Mobile, etc.) shall be the preferred multifactor authentication mechanism. For non-DoD personnel, another approved multifactor authentication solution (e.g., SMS or app-based authentication) shall be employed to ensure access is properly given, and continuous authentication shall ensure access is correctly maintained over time. The Contractor solution shall leverage Privileged Access Management tools and/or techniques according to Zero Trust principles to restrict privileged actions to authorized staff and to track all privileged actions.

1.4.4.4 Production Support Analysis

The Contractor shall analyze problems and solutions to detect and report trends and “worst actor” features and/or processes. These recommendations shall consider the simplest solutions first. For example, a trend in user errors for entering data might be solved by adding help text or changing data validations. On the other hand, recurring errors may require changes to functionality or the database. The Contractor’s expertise must be sufficient to support such analysis and to provide concise, actionable recommendations. For complex recommendations, the Contractor may have to collaborate with the Government or other Contractor personnel to create change specifications. Support analysis may also result in recommending changes to system documentation or training material.

1.4.4.5 System Data Analysis Support

The Contractor shall provide advanced-level reports, report query templates, and data dashboards for functional users in support of patient movement operations and research. Using the business intelligence analytics tool, the Contractor will be available to respond to FMO requests for reports, report query templates and data dashboards that can be downloaded. The Contractor shall be able to provide products within three (3) business days of receiving the finalized request.

Deliverables:

· Business Intelligence analytics tool report query templates and data dashboards

1.4.4.6 Cybersecurity Analysis

The Contractor shall monitor and analyze Information Assurance Vulnerability Management (IAVM) Notices, USTRANSCOM Security Notifications, United States Computer Emergency Readiness Team (US-CERT), and vendor security advisories. The Contractor shall determine system impact, identify mitigating factors, and provide recommendations to the Government regarding potential courses of action. The Contractor’s recommendations shall be compliant with DOD security requirements and industry best security practices. The Contractor shall ensure that cybersecurity remediation, patch deployments, and other significant security activities are considered in the Product Roadmap.

1.4.4.7 Cybersecurity Service Provider (CSSP) Support

The Contractor shall provide Host Based Security System (HBSS) and Assured Compliance Assessment Solution (ACAS) scans weekly; and shall participate in one (1) Continuity of Operations (COOP) exercise (i.e. Intrusion Assessment or Incident Response) annually.

1.4.4.8 Interoperability Certification Support

The Contractor shall ensure TRAC2ES maintains interoperability certification by the Joint Interoperability Test Command (JITC) in accordance with Chairman Joint Chiefs of Staff (CJCS) Instruction 5123.01H. All documentation delivered also must meet recommendations and guidelines defined in DOD Instruction 8330.01. The Contractor shall comply with the most current version of each reference. The Contractor shall review and provide inputs (if applicable) to the TRAC2ES DODAF artifacts provided by the USTRANSCOM enterprise architecture team and review the Enhanced Information Support Plan (e-ISP).

1.4.4.9 Platform/Infrastructure Support

Until TRAC2ES is migrated to the DevSecOps Environment TC-UGC and TC-CGC, the Contractor shall provide System Administration (SA) and Database Administration (DBA) support focusing on architecting, deploying, maintaining and documenting TRAC2ES infrastructure in the current hosting environment. This includes, but is not limited to, the following activities: supporting the TRAC2ES infrastructure, promoting software deployments, security patching, incident and problem management, monitoring resource usage, application performance, and managing all system accounts. This position shall maintain a current Secret Clearance, with a current T-5 background investigation, and current Foundational and Residential Qualification. (See Para 5.3)

1.4.4.10 Commercial Off The Shelf (COTS) Support

The Contractor shall provide support services for changes in COTS products to include patches (e.g. application, operating system, database), upgrades, and/or migration to newer technologies. This will involve analyzing the system for incompatibilities and deprecated features. Once prioritized by the Government, the Contractor shall refactor the necessary code to ensure continued system stability.

1.4.4.11 Training Services

The Contractor shall provide support services for changes in COTS products to include patches (e.g. application, operating system, database), upgrades, and/or migration to newer technologies. This will involve analyzing the system for incompatibilities and deprecated features. Once prioritized by the Government, the Contractor shall refactor the necessary code to ensure continued system stability. The Contractor shall provide training services to new users of TRAC2ES as required by the Government. The training services shall include, but not be limited to, instruction on the use of the System, its features, and its functionality.

1.4.4.11.1 Scope of Training

The Contractor shall provide training to new users of the System, including, but not limited to, the following: Department of Defense (DoD) personnel, including uniformed and…

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .