Atch 1 - PWS Rev.1 TC.docx

Program Executive Office USTRANSCOM (PEO-T)

Performance Work Statement (PWS)

For

Integrated Data Environment & Global Transportation Network Convergence (IGC)

15 May 2024

Table of Contents

List of Tables

Description of Services 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. USTRANSCOM provides synchronized transportation, distribution, and maintenance, which makes possible projecting and maintaining national power where needed with the greatest speed and agility, the highest efficiency and most reliable level of trust and accuracy.

Integrated Data Environment & Global Transportation Network Convergence (IGC) is the DoD system of record for In-transit Visibility (ITV). ITV capabilities provide customers the ability to track the identity, status, and locations of DoD unit and non-unit cargo and passengers, leveraging data provided by the military Services, commercial carriers, the Defense Logistics Agency (DLA), USTRANSCOM, and USTRANSCOM's components. IGC integrates that data and makes it available to the users and supporting systems to include historical data. The enabling Asset Visibility (AV) capabilities provide global visibility of assets in many classes of supply, which are organized by categories: In- Process, In-Storage, and In-Transit. Utilizing IGC, USTRANSCOM optimizes the effectiveness and efficiency of the DoD logistics pipeline in support of the users, Military Services, Combatant Commands (CCMDs), and subordinate Joint force commands including Joint Task Forces (JTFs).

Objective The objective of this requirement is to provide software development support and expertise for IGC. 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, product baseline, the hosted environment, web services, security, 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.

Scope The contractor shall provide agile software development support for IGC, support transition from a Waterfall to Agile SDLC methodology, and support migration from a Defense Information Systems Agency (DISA) Defense Enterprise Computing Center (DECC) to a cloud hosting environment. 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 project management and reporting, business requirements analysis and specification development, design analysis, web service development, software integration, data conversion, testing, release management, technical support, and documentation to support program processes and requirements.

Further, the contractor shall provide Operations and Maintenance (O&M) support. The contractor shall manage IGC, which currently resides in two DISA DECCs for development, test, non-production, and production.

IGC is currently scheduled to migrate to the cloud during the life of this contract. The cloud environment will reduce/revise the O&M requirements currently included in the scope of this PWS. The Government will incorporate any changes via bilateral modification when and if such changes occur.

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

Performance Requirements The contractor shall use a Government owned Application Lifecycle Management (ALM) tool (i.e., 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 Government Validation Testing (GVT), and keep artifact statuses updated (artifacts are the method for identifying a change with software which will be deployed into Production). To maintain predictable velocity, the developers shall 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 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, will typically be planned for four to five weeks in length, and shall result in a releasable product. The contractor shall execute up to 12 sprints per year. See notional sprint schedule in Table 1: Notional Sprint Schedule.

Table 1: Notional Sprint Schedule

* Notional Schedule assumes Sprints start on Wednesdays

The system performance requirements, for which the contractor is responsible for are the Low Side and High Side production environments. The contractor shall ensure the IGC availability meets a threshold of 99.58% for each month (i.e., 717 hours, which is a total of three (3) hours of unscheduled downtime). Front-end availability, defined as the ability to query data via a web browser. Front-end system components include web servers; BI servers; attached storage; and Lightweight Directory Access Protocol (LDAP) servers. This availability excludes four (4) hours of IGC scheduled down time per month, and hosting outages (scheduled and unscheduled). Back-end availability is the ability to process, store, and access supply and transportation data in the Enterprise Data Warehouse (EDW) (including all data stores). This availability excludes hosting environment outages (scheduled and unscheduled); provider system down time; Cross-Domain Service (CDS) down time; and four (4) hours of IGC scheduled down time per month. The contractor shall leverage the inherent IGC redundancy, high availability architecture, and system failover capabilities in meeting these availability requirements. Query performance standards are defined below:

For Standard Reports: User Interface defined screens and queries shall return 85% of reports per following rates: Simple Queries (an interrogation created with three or fewer joins) shall return in less than 30 seconds; Complex Queries (an interrogation created with more than three (3) joins) shall return in less than 60 seconds.

For ad hoc queries: 80% of ad hoc queries shall be completed and viewable to the user per the following rates: Simple Queries shall return in less than 120 seconds; Complex Queries shall return in less than 300 seconds; Extended Queries (an ad hoc interrogation created with more than three joins) shall return in less than 30 minutes.

NOTE. Two (2) criteria will define IGC availability: a user (front-end) measure and a system (back-end) measure. For both, availability will be measured by Operational Availability (A0), defined as the ratio of system availability to total time. A0 will be calculated as follows: A0 = Time System Available / Total Time, where Total Time = Time System Available + Time System Unavailable. A "Downing Event" is any hardware or software failure or preventative maintenance measure that prevents user access to any of the IGC threshold operational performance requirements. IGC must meet the front-end operational availability for the user as follows: A0 = 717 Hrs/(717 Hrs + 3 Hrs) = 0.9958.

The contractor shall notify the Government of system outages within one (1) hour of discovery of an issue. The contractor shall provide follow-up notifications to the Government when status changes. After system resolution, the contractor shall provide a System Resolution Report (SRR) within one (1) business day to the Government summarizing the issue, causes, remedies, and actions required to prevent re-occurrence.

Data availability description is provided to facilitate clarification and calculation of the availability metrics. Data availability is defined as the time between initial receipt of source system data within the IGC EDW environment, to the time the data is made available to the customer via the IGC low and high-side Global Tracker Application (GTA) and customer services (e.g., customer system queries, remote access applications, and the IGC Front Page). The threshold for data availability is 95% of all data maintained by IGC. For the unclassified and classified feeds, raw data shall be available for query within twenty (20) minutes of receipt of incoming feeds. For the unclassified system, all other data shall be available for query within sixty (60) minutes of receipt. For the classified system, all other data shall be available for query within sixty (60) minutes. Data availability caused by source system data feed fluctuations (e.g., large influx of data, data catchups, etc.) are excluded from the data latency calculation. The contractor shall notify the Government within thirty (30) minutes via email to the Government Production Support Manager when data latency exceeds the latency threshold.

Task Area 1: Contract Level and Task Order Management (Firm Fixed Price [FFP]) (Fiscal Year (FY)24-FY29 T-OPS) 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.

The contractor shall provide support by preparing documents such as required briefings, point papers and meeting minutes related to status of the performance of this PWS.

The contractor shall provide support in the specific areas outlined below in this PWS. The contractor shall work with the IGC Program Office, process owners/stakeholders, Federal and DoD Government representatives, and other contractors to accomplish required tasks.

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

Product Backlog Contains the complete set of prioritized Epics, Features, and User Stories with bi-directional traceability to the program requirements and highlights known work yet to be completed. The product backlog is a key product to manage development when using Agile methodologies.

Software Development Plan (SDP) Provides the Government insight into, and a tool for monitoring, the processes to be followed for software development, the methods to be used, the approach to be followed for each activity, and project schedules, organization, and resources.

Contractor Transition Phase-In (FY24) This transition period will provide thirty (30) 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 IGC Computing Environment 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.

Kick-Off Meeting (KOM) The contractor shall attend a KOM with all partners to establish a baseline of understanding after the contract award at a location to be determined by the Contracting Officer’s Representative (COR) within ten (10) business days of contract start. Participants will include Program Manager (PM), Government Technical Lead, Contracting Officer (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 a 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 TOMP 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 and 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 GVT (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 2: Notional Release Example

10.3.1

The MSR is due to the Government no later than the 10th business day of each month. The MSR format will be agreed upon by the COR and the contractor and shall contain, but not limited to, the following information:

· Activities conducted and results

· Deliverable Status

· Travel data, to include name of traveler, trip location and purpose, estimated and actual travel costs, and dates of travel

· Meetings attended with a summary of relevant items discussed

· Proposed activities

· Risk assessment and mitigation recommendations

· Open issues

· Actual and projected cost expenditures

· Labor hours by task and labor category

· Key personnel changes

· System availability and outages

· Security Summary analysis and assessment results

· Contractor Furnished Equipment (CFE) Information Assurance (IA) compliance verification

· Quality assurance and Configuration Management (CM)

· Key Performance and Capacity Metrics

· Analysis Task Status for the Reporting Period

· Production Support Tickets, Metrics, and Reports

· Number of total production support tickets, the status, listed in order of oldest to newest, average age of ticket with any trends identified (i.e., comm, account management, etc.)

· Available data storage space (available versus used and ninety (90)-day rolling trend)

· Production Support Actions by Shift

· Feed Statistics

· Rolling thirty (30)-day Trend Charts (Production Support)

· Software Versioning and Lifecycle; to include FOSS/third-party software versioning (IGC version and most recent version)

· Number and Processing Time for Query Reports (NIPR & SIPR)

· Numbers of Business Objects (BOBJ) Users and Queries (NIPR & SIPR)

· Numbers of Web Service Customers and Queries (NIPR & SIPR)

· Numbers of COGNOS Users and Queries (NIPR & SIPR)

· Rolling 12-month Data Storage Capacity Projection (NIPR & SIPR) Deliverable:

Monthly Status Report (MSR) Weekly Status and Planning Meeting The contractor shall participate in weekly status and planning meetings as directed by the Government. The contractor shall provide a weekly Task Area Status Report (TASR) that lists the accomplishments of the reporting period by each active task/project area and provide schedule updates. Focus areas are:

· Current Sprint

· Tasks and Schedule Updates

· Operations and Site Configuration

· Security

· Blocking Issues

· Planning Sprint +1

· Requirements Management

· Planning Next Sprint

· Administrative

· Upcoming calendar events

· Pertinent issues as agreed upon by the Government

· The TASR is due to the Government by Wednesday of each week.

Deliverable:

· Task Area Status Report (TASR) Employment Status Report The contractor shall provide an employee status report containing names, labor categories, and certification status of personnel supporting each major task. The report shall be provided within twenty (20) business days after contract award and within five business days after changes in personnel occur.

Deliverables:

· Employment Status Report

· Employment Status Report Updates Reporting inputs will be for the labor executed during the period of performance during each Government FY, which runs October 1 through September 30.

Configuration Management This support is required to maintain the DoD technical and security requirements. The CM process facilitates orderly configuration identification, change identification and control, status reporting and configuration auditing of product information for such beneficial purposes as to revise capability; improve performance; reliability; or maintainability; extend life; reduce cost; reduce risk and liability; or reduce defects.

CM ensures that changes take place in an identifiable and controlled process and do not adversely affect the properties of the other system or interfaces. CM establishes and maintains the integrity of the products of a project throughout the project life cycle. CM involves identifying the configuration items of products developed and delivered to the customer, systematically controlling changes to the configuration, and maintaining configuration traceability. The contractor’s CM processes must complement the Government configuration management processes.

Requirements Management The contractor shall be responsible for facilitation and administration of the IGC requirements management process. The contractor shall manage the activities necessary to receive, verify, analyze, refine, and confirm requirements provided by the IGC PM. The contractor shall also manage the activities necessary to maintain the IGC requirements baseline, track requirements status, maintain requirements versions, maintain requirements attributes, control requirement quality and consistency, perform change impact analysis, and provide reports. When directed by the Government, the contractor shall provide an analysis of level of effort, impacts to program costs and program schedule.

Configuration Management Plan The contractor shall develop a Configuration Management Plan (CMP) and processes that are consistent with the Government CMP and processes. The contractor shall establish and maintain the following:

· CMP organization

· Methods, procedures, and controls

· Baselines (versioning)

· Configuration identification

· Change control

· Configuration status accounting

· CM audits of total configuration to include hardware, software, and firmware

· ClearCase CM Repository

· CM Process The draft CMP is due within twenty (20) business days of contract award. The final CMP is due within five (5) business days after receiving Government comments.

The contractor shall utilize a strict version control process for software development and deliver complete source code for all software versions developed under this contract.

Deliverable:

· Configuration Management Plan Configuration Identification The contractor shall provide Configuration Identification (CI) as specified in their CMP. This identification may include hardware configuration items or software configuration items. All configuration items must be uniquely identifiable by use of a configuration item number and nomenclature (serial number can be used for hardware and version number can be used for software). In addition, the contractor shall provide a Configuration Item Listing (CIL) showing the software installed on each piece of hardware (Government format). The draft CIL is due within twenty (20) business days of contract award and each POP.

Deliverable:

· Configuration Item Listing Configuration Management Audits The contractor shall conduct a physical and functional configuration audit of each code baseline/release delivered to the Government. The Government reserves the right to participate in the audits if desired.

Data Management The contractor shall maintain a data management program, as well as the IGC Collaboration Portal hosted at the DECC for hosting all technical data and computer software used on or produced in the performance of this contract. The purpose of the Collaboration Portal is to create a seamless, collaborative data environment for the contractor and the Government team, which contains all pertinent data about the project throughout its development and delivery. All items posted to the Collaboration Portal, including drafts of deliverables that are not final versions, shall be considered delivered for purposes of the Defense Federal Acquisition Regulation Supplement (DFARS) data rights clauses (and subject to the same rights asserted for final deliveries). However, these non-final versions shall not constitute acceptance for purposes of Inspection and Acceptance requirements or the DFARS data rights clauses.

Contractor Transition Phase-Out (FY29) 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 in-progress working files to include, but not limited to a copy of all recent deliverables. Also, the contractor shall execute a final phase-out meeting with Government, and the new contractor. The contractor shall support a formal contract closeout process, to include documentation of lessons learned throughout the life of the contract. All deliverables shall be provided forty-five (45) calendar days before the end of the contract period of performance.

Deliverables:

· Transition Plan

· In-Progress Working Files

· Lessons Learned Task Area 2: Software Development Support [FFP] (FY25-FY29 T-OPS) The contractor shall provide two scrum teams equal to six Full Time Equivalents (FTE) on each team per sprint. This task includes responding to requirements 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 and product backlog. The contractor shall use the Agile Scrum Framework to execute extreme programming (xP) 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 GVT. 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) 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).

The contractor shall meet all Government specifications for design, development and implementation of secure applications and configurations through applying secure software development processes and secure coding practices with each software release candidate. These include but are not limited to applicable DoD Security Requirements Guide (SRGs), Security Technical Implementation Guide (STIGs), industry best practices, vendor security guidance, and applicable product security patches. The contractor shall ensure software code does not contain programming errors listed on the current approved version of the Common Weakness Enumeration (CWE), the SANS TOP 25 Most Dangerous Software Errors, the Open Web Application Security Project (OWASP) Top Ten, or an unsecure configuration found by applying the DISA Application Security and Development Security (ASD) STIG, applicable Enclave Test and Development (T&D) and application STIGs/SRGs.

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 release notes (i.e., Jira tickets done) static code scans (e.g., Fortify, SonarQube, TruffleHog), release test plan with results, GVT plan with test scripts, and minor mod checklists, which include all artifacts with associated descriptions and solutions, and deployment instructions. The contractor shall support GVT, Government Acceptance Testing (GAT), and provide release reports via ALM tool to include pass/fail status of each task during sprint for sprint review. The contractor shall provide a demonstration (i.e., video of tested functions) of tasks completed during GAT for Product Owner (PO) and/or Business Owner (BO) acceptance. This will lead to GVT for government testing and validation. Once completed the BO confirms that the testing and development has met the acceptance criteria outlined in test requirements.

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, and 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), DISA STIGs, DoDI 8530.01, and the DoD Cloud Computing Security Requirements Guide.

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 GVT 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 minor mod checklists (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.

The contractor shall ensure all products and components have vendor support and replace or remove any products or components prior to becoming “end of life” (EOL) or “end of support” (EOS). The contractor shall not utilize EOL, EOS, or “extended support” hardware, software, firmware, or computer code unless specifically approved by the Government.

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.

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. The contractor shall be required to design, build, implement, and test upgrades and enhancements offered by a COTS vendor. This will involve analyzing the system for incompatibilities and deprecated features; and includes keeping Third-Party Libraries (TPL) up to date. 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.

Deployment Pipeline Support Once IGC is migrated and operational in an Unclassified and Classified Government Cloud, the contractor shall provide expertise required to operate and maintain the Development, Test, 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 Internet Protocol (IP) Addresses information. Air Force Department of Defense (AF-DoD) approved PPS worksheet will be used; available on the PPS Management at https://intelshare.intelink.gov/sites/ppsm.

Static Application Security Testing (SAST) Support The contractor shall run static code scans on the entire application using Government approved code scan tool(s) (e.g., Micro Focus Fortify, SonarQube, TruffleHog) to prevent or mitigate potential security vulnerabilities from being deployed into the Production environment. The contractor shall provide new scans along with analysis for every release candidate inclusive of all software code. This includes: 1) existing software code, 2) new software code, 3) refactored software code (changing the source code without modifying external functional behavior), and 4) TPL that were modified or evoked for inclusion in the application. Non-functional (non-evoked) software code within the TPLs will not be included in scan output. The contractor shall follow USTRANSCOM policy regarding scan engine and rule pack versioning as determined by release candidate delivery date. The contractor shall provide code scans results in plain text format, and encoded components (i.e., base64 images) shall not be included. The contractor shall analyze code scan results to remediate findings or provide rationale on false positives. The contractor may mitigate findings to a lower severity with Government approval.

The contractor shall annotate open findings, along with fix or proposed mitigation actions, using a Plan of Action and Milestones (POA&M) for Government approval. The contractor shall develop a Burn Down Plan for inclusion withing the Product Roadmap. For findings requiring code changes, the contractor shall enter the findings and recommended fix actions into the Government ALM tool for prioritization into software development sprints for remediation.

The contractor shall assist the Government Information System Security Manager (ISSM) with conducting an annual review of scan findings to ensure the POA&Ms and Burn Down Plan accurately reflect the current risk posture of the software. The contractor shall provide the results of each review to the Government.

DoD Security Requirements Guides (SRGs) and STIGs Compliance Support 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 (e.g., operating system, database, servers) complies with the most up-to-date version of the DoD SRGs and Application Security and Development STIGs. The contractor shall remediate any non-compliant checklist items. The contractor shall enter open STIG findings, along with fix actions, into the Government ALM tool.

Development Security Operations (DevSecOps) Support The Contractor shall follow the DoD Enterprise DevSecOps Reference Design (see Appendix A: References for url) if developing in USTRANSCOM hosted development environments. The contractor shall adhere to all policies and procedures established for the authorization boundary of USTRANSCOM hosted development environments.

Surge Support This task area may require surge support for sprints which may run concurrently with the notional sprint schedule identified in PWS paragraph 1.5. The contractor shall provide one scrum team equal to 6 FTEs on a team per sprint for up to 6 additional 4 week sprints per PoP. The Government will provide a minimum of forty-five (45) days notice for surge support in this task area.

Task Area 3: Monitoring and Production Application Support [FFP] (FY25-FY29 T-OPS) This task includes monitoring and troubleshooting production applications; and responding to incidents that are generated by system users. Production support, Level II and III Help Desk, tickets shall be generated within the Government ALM tool. Production support tickets are the method for tracking and resolving incidents (i.e., specific issues). 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 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 all incidents are documented clearly.

The contractor shall provide operations services for all environments and installed COTS/applications to include: IGC Tool Suite, IGC EDW development and test environments, IGC EDW unclassified primary and alternate production environments, and IGC EDW classified primary and alternate production environments. The contractor shall maintain and update the Operations Guide as operator procedures are refined and evolve.

Additionally, in the event of changes made by an interface partner, the contractor shall support validation and verification of existing system interfaces.

Deliverables:

· Production Support Report This report will provide updates on all issues opened, updated, or closed during the previous 24 hours. Issues include, but are not limited to, alert/alarm information and corrective actions, reach back support and contact, outage and availability details, maintenance Authorized Service Interruption (ASI) details, feed processing outage details, and any event that required manual or automated recovery actions to eliminate or reduce impact to the customer. If the contractor has detected a trend, this report shall include a 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. A copy of this report shall be e-mailed daily (Sun-Sat) at 0600 to the Government Production Support Manager.

· 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 hours of the event. The Cyber Intrusion Incident Report Update is due within twenty-four (24) hours of the event.

· Operations Guide This guide is used to monitor and maintain IGC on a day-to-day basis, to include routine tasks performed by the production support staff. The document contains a high-level description of IGC that includes but is not limited to IGC Overview, IGC System Architecture, and High Level Data Flow. An updated Operations Guide shall be delivered quarterly.

· Architecture Diagrams The diagrams are used in support of the USTRANSCOM J6 Enterprise Architecture Team annual reviews and for Joint Interoperability Test Command (JITC) certification submissions.

· JITC Document Updates The documents are required in support of joint interoperability testing. They include test data required in support of JITC.

· Web Services Catalog This catalog includes a revision history, table of contents, web service name, and data parameter details for each web service. This catalog is used internally and externally to support current and emerging web service customers.

· Web Services User Guide This guide is used internally and externally to support current and emerging web service customers. The guide shall include guidance for interface partners to utilize the IGC web service offerings.

Monitoring Support The contractor shall provide monitoring support twenty-four hours a day, seven days a week to monitor current health, performance statistics, recent errors, full logs, and key metrics of the IGC program. The contractor shall ensure the system is working normally; and report and resolve any breaches, security attacks, degradations, outages, or anomalies in activity. The contractor shall use log collection, monitoring, and analysis to understand the relationship between network, infrastructure, servers, application framework, data feeds health, data feed latency, databases, reference data, 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 IGC 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. This support shall be performed onsite at SAFB or the Alternate Operating Facility Continuity of Operations (COOP) scenario. The Government will provide onsite workspace for this task.

Production Support The contractor shall respond to and resolve operational problems with the IGC system and tool suite. This task includes responding to incidents, analyzing and correcting specific incidents, creating software development artifacts (i.e., Jira tickets) 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.

This task also includes resolving COTS related issues, system interface issues, CDS issues, system access issues, web restarts, front-end/back-end repoints, performance issues, and other required tasks as defined in the Operations Guide. The contractor shall coordinate with commercial vendors and other Government service providers to provide hardware, interface, and software support.

The Contractor shall maintain an on-call capability to assist the Production Support Staff (if required) in resolving Severity 1 issues affecting availability or data latency on incoming/outgoing interfaces. The on-call response time is thirty (30) minutes, measured from the time of receipt of the production support staff call to the time the standby personnel have acknowledged the call for support. Production Support Staff shall work closely to assist in resolution of reported problems.

The contractor shall…