2023.10.11_PWS_GTP-GOPAX_RFI.docx

Program Executive Office USTRANSCOM (PEO-T)

Performance Work Statement (PWS)

For

Global Transportation Planning (GTP) And Groups Operational Passenger (GOPAX) Systems

01 Oct 2024 [(INTERNAL) Version Number 7.0]

UNCLASSIFIED

UNCLASSIFIED

Table of Contents

List of Tables

UNCLASSIFIED

UNCLASSIFIED

1. Description of Services Background

GTP

The purpose of Global Transportation Planning (GTP) is to provide improved time-definite delivery and best-value transportation solutions to fully support combatant commanders’ movement requirements. GTP is an umbrella program (composed of several applications, See Table 1-1) that integrates and governs enterprise-to-enterprise (E2E) distribution process optimization initiatives including continuous business process improvement, process visualization and dynamic transportation decision making. Using enabling technology, these initiatives provide operators with new insights to solve distribution pipeline challenges quickly and collaboratively yielding enhanced E2E delivery of forces and sustainment to the warfighter. GTP supports continuous and distributed joint force operations, demanding unprecedented logistics agility and precision through process improvement, organization, and IT. GTP must support global maneuvers across inter-theater distances and operational maneuver throughout the geographic (Combatant Command’s (CCMDs) Areas of Responsibility (AORs) and must be able to manage and sustain distribution and deployment support to widely dispersed joint forces over a large area of operations. GTP aids the Distribution Process Owner (DPO) in the successful accomplishment of both strategic and operational capabilities of the distribution E2E process through IT.

USTRANSCOM considers Business Process Management (BPM) enabled by Continuous Process Improvement (CPI) as foundational to support the operational outcomes required for E2E optimization of the movement of forces and sustainment, passengers and cargo, as well as achieving the capability to coordinate and synchronize Joint Deployment and Distribution Enterprise (JDDE) activities. In 2010, USTRANSCOM began BPM, technology development and integration and related data services integration in support of GTP and Groups Operational Passenger (GOPAX) systems requirements. The Government coordinates and synchronizes these efforts as part of the overall GTP and GOPAX capabilities development.

Voyage Calculator The Maritime Sustainment Command (MSC) Voyage Calculator (VC) capability was initially developed by MIT Lincoln Labs (LL)) to provide COAs to senior leadership based on ROM estimates of the numerous costs associated with operating ships throughout the various stages of the voyage, such as determining fuel usage while underway and costs associated with port and canals. The VC underwent development starting in 1QFY23 to incorporate the capability into the GTP Unclassified (NIPR) environment, including refactoring of the application to meet DoD security standards, implement an approved IdAM solution, and modernization/containerization to operate in USTC’s TCODE environment. The developer refactored VC to convert from Python (current operating language) to Java (language used for GTP applications and containerize and adapt for operations, and integrate into the TCODE IL-4 environment.

GOPAX

The Groups Operational Passenger (GOPAX) system fulfills the operational requirement of moving groups of passengers throughout the Continental United States (CONUS) for USTRANSCOM. GOPAX continues to provide the Command’s operational capability for securing cost-effective lift for domestic group passenger movements. While GOPAX is a separate program of record, GOPAX and GTP share similar technical architectures and environments. The processes identified in this PWS apply to both programs, except where identified.

Objective The objective of this requirement is to provide software development support, IT security, administration, and expertise for the GTP, GOPAX, and VC systems (applications and supporting environments). This includes all software code and associated components and integrations. Software development support shall include all aspects of the Software Development Lifecycle (SDLC) necessary to sustain and modify the system baseline. Responsibilities include managing the code baseline, the hosted environment, and system interfaces. The code baseline may change as a result of user preference, latent defects, change requests, security requirements, or updates to Commercial-Off-The-Shelf (COTS) products used by the system. Additionally, the Contractor shall provide production support to include troubleshooting and resolving user problems as well as identifying opportunities to improve the system. 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 assist the Government in adapting, adopting, and maturing Government Off-the-Shelf (GOTS) and COTS technologies for integration of capabilities into the operational architecture. The Contractor shall plan for and provide:

· Software engineering and application development support for each of the supported applications identified in Table 1‑1

· Sustainment of the supporting development and production environment support services for each of these applications (as required), including help desk support and monitoring

· Sustainment of the Platform and its supporting environment(s)

· Cloud planning and migration (as required), to include refactoring of applications to enable hosting in new, non-specified environment

· Development of emerging software capabilities (as required)

· Maintaining/providing accreditation requirements for all applications and supporting environments Table 1‑1 Supported Software Applications Functional Agency

(Current/Projected)

Application Development The Contractor shall provide agile software development support for each application as approved by the Government. 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.

Agile Application Development The Contractor shall propose/provide a number of Scrum Teams to include appropriate labor mix of team members and equivalent FTEs with one (1) Certified Scrum Master. The Government will appoint a Technical Product Owner to complete the team. Each application (App) has a Functional Area Manager (FAM) who is a user of their respective App. Each Scrum Team shall be self-organizing. The self-organized Scrum Team is self-reliant and self-sufficient in terms of accomplishing their work without the need for external help or guidance. Each Scrum Team is competent enough to adopt the best of practices to achieve Sprint Goals. Each Scrum Team shall be cross-functional. The cross-functional Scrum Team has all the necessary skills and proficiency within the Scrum Team to accomplish their work. A Scrum Team does not rely on anyone outside the Scrum Team for completing the work items. Therefore, each Scrum Team shall be an amalgamation of different skills that are required to complete the entire work item. Each team member may not necessarily have all the skills required to build requirements but is competent in his/her area of expertise. For Sprint Planning: Each Scrum Team shall have the ability to estimate story point sizes for requirements delivered into the backlog by the FAMs or Gov Technical reps for prioritized work. Each Scrum Team shall have an estimated Story Point Capacity for their Sprint/release cycle and use this when setting goals and stretch goals for a Sprint.

Development / Production Environment(s) Sustainment The Contractor shall provide expertise to build and maintain the applications’ development, non-production, and production environments within an identified Amazon Web Services (AWS) Government Cloud (TCODE/GTPCloud/GovCloud). Specifics for this effort are outlined in Task Area 5.

Per USTRANSCOM current IAWIP guidance, based on DoDI 8570, the Contractor shall have IAT II certification for the Program Lead Developer and all Program Cloud Developers. The Contractor shall provide an IAM III Certified Information Systems Security Professional (CISSP) to support all task areas. Please note though that DoDD 8570 has been rescinded by DoDD 8140. USTRANSCOM is currently working the new IAWIP policy in line with DoDD 8140 and the process to transition within contracts. Until that time, current USTRANSCOM policy remains in effect.

TCODE

The Contractor shall ensure that applications are developed to be used within the approved USTC cloud architecture (TCODE), which enables software deployments from the development, non-production, and production environments using Gitops tooling provided by the software platform. All applications will need to implement Government-specific security controls on the application and be able to achieve an authorization utilizing inheritance from the software platform.

Non-TCODE Clouds (AWS GTPCloud (Cloud One), USTC GovCloud) The Contractor shall provide expertise to build and maintain the application development, non-production, and production environments within the approved Cloud environment (i.e., Cloud One and USTC GovCloud). While all applications will eventually be hosted in TCODE, the GTP-U (TCJ5/4) applications and GOPAX will be hosted outside of TCODE until migration to TCODE can be accomplished. Hosting within these environments may require additional refactoring of the architecture to support changes to the applications in preparation to migrate to TCODE or as changes are made to the TCODE environments. All clouds are hosted by Amazon Web Services (AWS).

DevSecOps Pipeline The Contractor shall provide support in the discipline of Development/Security/Operations (DevSecOps) environments. This support shall include expertise with Continuous Integration/Continuous Deployment (CI/CD) and the use of software build pipelines.

Application Requirements/Capabilities/Backlog Managment The Contractor shall manage the activities necessary to receive, verify, analyze, refine, and confirm requirements provided by the Program Manager (PM). The Contractor shall also manage the activities necessary to maintain program requirements baseline, track requirements status, maintain requirements versions, maintain requirements attributes, control requirement quality and consistency, perform change impact analysis, and provide updates to the status of ongoing activities.

The Contractor shall use a Government-owned Application Lifecycle Management (ALM) tool (Currently Jira and Confluence) 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 predictable velocity, the developers shall complete the artifacts they commit to in each software sprint IAW Section 4.8 of this PWS, and Scrum 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 using the Government-provided ALM tool. Each assigned requirement will have one or more associated artifacts.

The software development sprints are defined by the Government. Sprints are planned for three (3) weeks in length but may change at the Contractor’s request and Government’s approval. Sprints may be at minimum two (2) weeks but may not exceed four (4) weeks in length, and result in a potentially deployable product.

References All references to including electronic libraries can be found in Attachment 1_References_v5.

Surge Support The Government may require surge support during the base or any option period on any Task Area or CLIN. Surge modifications will be within the scope of the contract and provide increased support for the defined task areas of this PWS. This will be a priced optional task to expand the scrum team(s), and can be awarded in two (2) month increments. Surge support over the life of this contract will not exceed 35 % of the Contractor’s total proposed cost/price for the base and all of the options, excluding any two (2) month extension of services pursuant to FAR 52.217-8.

The services provided within the scope of this contract are considered Operationally Critical Support (OCS) and Covered Defense Information (CDI) as defined in Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012, "Safeguarding Covered Defense Information and Cyber Incident Reporting.”

Core Government Processes and Procedures The Contractor shall comply with and utilize all Government identified process and procedures, including those outline in USTC Operating instructions and PMO plans and guidelines. These processes and procedures will be provided to the Contractor. These process and procedures they may evolve based on changing requirements and/or priorities, evolving missions or external factors, they are nonetheless owned and managed by the Government and not up for negotiation. Suggestions for improvement can be made, but must be approved by the Government PM. These processes and procedures include:

· Test & User Acceptance

· Tollgate/Release Delivery

· Minor Mod

· Deliverable Acceptance

· Requirements Grooming/CCBD (applications)

· New Software Approval (CCB) (SAs)

· Change Control (SAs)

· Backlog Grooming (non-CCBD)

· New-Hire, Account Approval

· Incident Notification (IR/CP) Task Areas Task Area 1: Task Order Management

[FFP] (FY25-FY29, TWCF-OPS)

To support Task Area One (1), the Contractor shall provide one (1) Program Manager and support staff.

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 (POC) for both management and technical matters. In addition, the Contractor shall participate in daily or weekly Tag-ups, Integrated Product Teams (IPTs), TEMs, and various impromptu (usually virtual) meetings where the status of the work and associated deliverables are reviewed in the context of the business processes supported by the system.

Task Order Management Task Order Management Plan The Contractor shall deliver a Task Order Management Plan (TOMP) that documents the Contractor’s approach, timeline, and tools to be used in execution of this effort. The TOMP should take the form of both a narrative and graphic format that displays the schedule, milestones, risks, and resource support. The TOMP shall also include how the Contractor shall coordinate and execute planned, routine, and ad hoc data collection reporting requirements as identified within the PWS. The Contractor shall update and maintain the Government-approved TOMP throughout the PoP. 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 Contractor Transition Contractor Transition Phase In ([FY24, TWCF OPS]) The phase-in period shall be from 1 Sep 24 – 30 Sep 24 (30 days) During this period, the incoming Contractor will be provided transitional training and will work side-by-side with or shadow the outgoing Contractor on the local processes and procedures for performance of day-to-day duties, specifically deliverables. This effort is not functional in nature but 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 identified Government cloud, program cloud tools, and developing plans and procedures. The Contractor shall be authorized access to Government facilities at 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 TEAMS application, or other authorized collaboration tool. The Contractor shall provide minimal staffing for this period. At the end of the transition period, the Contractor shall assume responsibility for completing all tasks identified in this PWS.

Kick-Off Meeting (KOM) ([FY24] TWCF OPS) 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 develop the agenda and briefing 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

· Identification of Task Area staffing, including Task leads and other key personnel

· Other relevant items may be introduced at the discretion of the Contractor and/or the Government In addition, the Contractor shall capture minutes from the KOM and submit minutes and action items to the Government within 5 days of the event.

Knowledge Transition and Transfer from the Previous Contractor The Contractor shall provide transition and knowledge transfer support for all tasks detailed within this PWS. The Contractor shall identify personnel to participate in the Knowledge Transfer and Transition (KT&T). KT&T will begin on 1 September 2024 and run through 30 September 2024. This will include the program overview, infrastructure, data flow, software tools and processes, COTS, application administration, training, incident and problem management, systems architecture, operations activities, security, and maintenance activities. This will consist of classroom, over the-shoulder (e.g., observe current Contractor working), and hands-on (e.g. perform tasks under supervision of current Contractor) phases as facilitated by the Government. The sum of these phases will be 30 calendar days. All meetings during this period shall be conducted within a 10-mile radius of SAFB. The Contractor shall ensure personnel having the respective skills identified in Section 4.7.

Turnover/Exit Transition Prior to contract expiration, or in the event of a different Contractor winning the 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 outgoing Contractor shall provide electronic copies of the following to the Government: 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.

The Contractor recognizes that the services under this contract are vital to the Government and must be continued without interruption. The Contractor shall provide for knowledge transfer to facilitate successful transition of duties and responsibilities from one Contractor to the other as well as to Government designated third parties as facilitated by the Government.

The Contractor shall document their strategy for transition of all tasks. The Contractor shall be responsible for preparation of all briefing materials and deliver the material to the Government prior to commencement of KT&T activities. The Contractor shall provide classroom, over the-shoulder (e.g., future Contractor observing current Contractor work), and hands-on (e.g., supervising tasks performed by future Contractor) transition to the future Contractor.

The Contractor shall prepare a 30-calendar day schedule that includes these three phases of KT&T and deliver this schedule to the Government at least two weeks prior to the commencement of KT&T. This shall include data flow, software tools and processes, COTS configuration, application administration, incident and problem management, systems architecture, operations activities, security, and maintenance activities.

The following items comprise exit criteria for KT&T and shall be provided by the Contractor to the Government in a Closeout Report:

· The Contractor shall organize all work-related documents and files, provide digital copies to the Government, and provide a file plan outlining the file structure

· Status for each project shall be documented, to include recent, current, and pending actions

· The Contractor shall provide a listing of all COTS utilized in support of this contract and soft copies of all procedures and training materials developed as part of this contract

· The Contractor shall provide a listing of all GFE & computers utilized in support of this contract and plan for distribution to incoming Contractor

· The Contractor shall provide a complete list of all badges, vehicle passes, and Government software access permissions by individual currently working on the contract The Contractor shall ensure no logistics or contract data is corrupted, lost, changed, or altered in a manner that would cause damage to the Government.

Tag-ups, Integrated Product Team (IPT) Meetings, and Impromptu Meetings The Contractor shall participate in Daily/weekly Tag-ups and Integrated Product Teams (IPTs) meetings using the TEAMS application or at the place of performance when directed by the Government (Tag-ups will occur either daily or weekly but should not include the entire cadre of Contractors—only key personnel (ie, task leads and PMs; IPTs will occur weekly). Meeting topics include, but are not limited to, updates on work in progress, requirements management, metrics, schedule updates, upcoming calendar events, and other pertinent issues. Tag-ups should last no more than 15-30 minutes; IPT meetings are expected to last sixty (60) minutes but may run longer. Impromptu meetings are unavoidable and should be hosted only when necessary if there is a specific and pressing issue that needs to be resolved and cannot wait for the next Tag-up or IPT.

Both the GTP and GOPAX programs use IPTs to maintain coordination and collaboration of development and sustainment activities across the enterprise. Both IPTs support all applications, environments, and meet weekly (each one occurring every other week):

· The Program Management (PM) IPT, chaired by either the Government PM or Deputy PM, conducts cost/schedule/performance oversight, risk and issue management, resource management and program planning activities

· The Technical (Tech) IPT, chaired by the Government Lead System Engineer, works in partnership with the Contractor Lead Engineer, to manage the technical development activities to include architecture, solution integration, security accreditation, and transition The Contractor’s PM will be expected to be prepared to address any issues relating to any task area or item in this PWS during these meetings and present these findings to the Government.

Technical Exchange Meetings (TEM) The Contractor shall attend TEMs to support interfaces, sustainment, and maintenance. The Contractor shall participate via TEAMS in recurring TEMs that will last approximately one (1) hour. At Government request, the Contractor shall travel to Scott Air Force Base, (SAFB) IL, or other locations, to participate in TEMs in person or via the DOD TEAMS application (or other collaboration tool as defined by the Government). The anticipated LOE for this subtask is (4) hours/month.

Monthly Status Report (MSR) The Contractor shall provide an MSR that includes by task the financial, schedule, performance, and risk and Key Performance Indicators (KPIs) IAW Attachment 2_Application Requirements Specification Guide. The system KPIs are for reporting purposes under the MSR only and do not constitute acceptance criteria under the terms of Sections 1.12 and 2 of this PWS. The MSR will include proposed changes to the schedule as detailed in the TOMP as well as property accountability, technical accomplishments, identify issues and risks with recommendations to mitigate, and planned activities for the next reporting period. The Contractor shall provide a table with information detailing the Contractor personnel assigned, required certifications, and associated certification status. Any issue requiring Government response or action shall be brought to the Government’s attention immediately upon identification, and status captured in monthly reports.

Each MSR 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, the Contractor shall 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.

Each MSR 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, each MSR 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‑2 – Notional Example

10.3.1

eCMRA (if Applicable) Contractor will provide a GFE & GPS Inventory Accountability Report, if applicable.

System for Award Management (SAM) The Contractor shall report in the System for Award Management (SAM) the following information: 1) the total dollar amount invoiced for services performed during the previous Government FY under the contract; 2) the Prime Contractor direct labor hours expended on the services performed during the previous Government FY; and 3) if applicable Tier 1 Subcontract number, including Unique Entity Identifier (UEI) and name, and the number of SubContractor direct labor hours expended under the contract. Reporting inputs will be for the labor executed during the period of performance during each Government FY, which runs October 1 through September 30. While inputs may be reported any time during the FY, all data shall be reported no later than October 31 of each year. Contractors may direct questions to the help desk at: http://www.ecmra.mil/.

The eCMRA site associated with this contract is http://www.ecmra.mil.

The Command of the Requiring Activity is AFELM USTRANSCOM.

The Unit Identification Code (UIC) for this requirement is FF0BD0.

The Federal Service Code for this contract is [TBD - depending on contract vehicle and work].

Deliverables:

· TOMP

· Product Roadmap

· KOM Agenda

· KOM Briefing Materials

· KOM Action Item Lists

· KOM Minutes

· Knowledge Transfer to Future Contractor Briefing Materials

· 30 Calendar Day KT&T Schedule

· Closeout Report Transition Plan In-Progress Working Files Concept of Operations (CONOPS) Procedures Lessons Learned

MSR

GFE & GPS Inventory Accountability Report Task Area 2: Application Software Development Support

[FFP] (FY25-FY29, TWCF-OPS)

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 as referenced in the PEO-T Agile Scrum Framework Guide, along with Extreme Programming practices (xP) 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 with analysis, unit testing, integration testing, and UAT. The Contractor shall use a microservices architecture for new code (e.g., newly developed or upgraded features), and decouple monolithic legacy code only when appropriate (e.g., failure isolation, multiple rates of change, simplify external dependencies, etc.) for long-term usability and scalability of the application. This would exclude any COTS products. Additionally, the Contractor shall use automated testing, security updates, configuration management, the software build process, etc. necessary to achieve Continuous Integration/Continuous Delivery (CI/CD). For applications that are not fully automated, the Contractor will use testing and other methodologies IAW Government-approved processes only. Manual processes will be rejected except under very limited circumstances approved by the Government.

Software Release Materials Source Code The primary deliverable of this task is software source code, system configurations, database schemas, etc. All software code, system configurations, database schemas, etc. associated with this task shall not contain any company proprietary markings, logos, or distribution restrictions and provide the Government with unlimited rights. Source code shall be installed in the Zone B Integration environment and tagged as a code segment via the Government-managed code repository (ie, GitLab) and/or delivered on other mutually agreed upon format.

Release Documentation The Contractor shall update software release documentation to ensure it properly accounts for all functionality. This shall include a work plan with recurring updates, static code scans (e.g., Fortify scans with analysis), release test plan with results (TRR), UAT plan with test scripts, and minor mod checklists (i.e., release notes), which include all artifacts listed below with associated descriptions and solutions, and deployment instructions.

In addition, the Contractor shall develop or update, Interface Design Description (IDD), Release Package, Software Design Descriptions (SDD), System Center Operator’s Manual (SCOM), Software User Manuals (SUM), architecture diagrams, and topologies as necessary to support the features and functions of operational software. The Contractor shall review the user manuals and training materials and update them based on current business rules. Additionally, the Contractor shall ensure that the documentation is consistent and update figures and diagrams to match current functionality. The Contractor shall document business rules, model logic, a data dictionary, and all information required to clearly document how the software operates.

The Contractor shall provide all software configuration code and data, compilation code and data, supplemental data, test code and data, source code and data, and installation code and data describing the version of the software being released. The contractor shall update the Software Bill of Materials when a change is made.

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, updated IT Asset Management (ITAM) listing, 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 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 Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG).)

Application Demos The purpose of these demos is to observe the design and other documentation is complete, complies with the established design and testing approach, is technically sound, and will satisfy the functional requirements as defined. For the purposes of confirming the Contractor’s code adheres to systems development standards, is technically sound, meets design requirements, and the test plan for the code under review is documented in accordance with Quality Assurance/Test standards, the Government reserves the right to have one or more representatives perform source code configuration, test, compilation, and installation script walkthroughs and create a detailed report.

Training Materials The Contractor shall provide user training via on-line, on-site, and local classroom instruction or recorded media such as videos. The primary method for delivering user training shall be on-line; however, the Contractor shall also provide user training via classroom instruction at Scott AFB and on-site at other locations for each capability release, if required and/or directed.

The Contractor shall provide training to enable operations of specified applications and processes. The Contractor shall develop and publish curriculums and training materials for training classes in coordination with the Government. The Government shall review and approve the curriculum and all training materials.

The Contractor shall provide user training to include at a minimum, application-level training, including hands-on training, in application-specific operations. The Contractor shall provide Administrator Training for designated Administrators to include, but not be limited to, account creation, account management, and monitoring of accounts, as well as user training. The Contractor shall be responsible for updating training material and class content to reflect system changes and enhancements. The Contractor shall assess the trainer, materials, and overall quality of training for each training class by soliciting student feedback via a feedback form.

In general, the training curriculum and training plan shall be delivered 20 business days after the contract award and updated 20 business days after the start of each contract period. Release-specific training materials will be provided within 10 business days after each release, as directed.

Agile Software Development 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 Government 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 minor modification 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.

Agile Performance Metrics Team Agile software development metrics (velocity) will be included in the MSR Includes:

Software Defect Support The Contractor shall respond to resolve 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. Severity one (1) issues shall be acknowledged within four (4) business hours and resolution provided within one (1) business day. Severity two (2) and three (3) issues shall be acknowledged within one (1) business day and resolution provided within five (5) business days per Table 5 – Severity Definitions. 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.

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. This will not involve change-over in technology (i.e., instead of Java, use .NET), but shall include patching upgrades so applications will not require extended support.

Deployment Pipeline Support The Contractor shall provide the expertise required to operate and maintain the Development, Non-Production, and Production environments to compile, build, and deploy code reliably and efficiently within the designated cloud environment. 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) /DOD) -approved PPS worksheet will be used; these are available on the PPS Management link at http://intelshare.intelink.gov/sites/ppsm.

Static Application Security Testing (SAST) Support The Contractor shall run static code scans using a Government-approved code scan tool (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.

To access the Government approved code scan tool, the Contractor shall provide documentation for an IAWIP package, which includes Security+ CE training renewed every three (3) years. Account management will be detailed and executed upon contract award.

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

Software Alternatives and Analysis The Contractor shall regularly analyze alternative approaches for fulfillment of application capability requests by performing functional analysis and technical benchmarking of COTS and Government-of-the-Shelf (GOTS) software when designing and implementing software features and software functions. The Contractor shall provide documented recommendations on GOTS, COTS, and internally developed solutions.

The scope of functional analysis includes:

· Using the same operational objectives, data, business rules, constraints and criteria, to evaluate GOTS optimization performance with COTS optimization performance

· Documenting performance baseline gaps between GOTS and COTS capabilities

· Providing recommendations on closing performance gaps between GOTS and COTS, supporting enterprise operational processes and decisions

· Comparing and contrasting the above solutions with respect to ease of use, resources and skill levels required, training, etc.

The scope of technical benchmarking includes:

· Analyze GOTS vs. COTS integration risks with other Government programs-of-record

· Provide recommendations on GOTS vs. COTS development risks and trade-offs

· Provide insights on scaling current GOTS vs. COTS capabilities to various transportation modes and multi-modal planning.

· Compare and contrast GOTS vs. COTS enterprise capabilities to change business rules, optimization models, and constraints to capabilities already being used within operations (e.g., ease of change, time to change, operator vs. developer required, ability to configure existing capabilities without new software development and releases) Upon acceptance by the Government, the Contractor shall develop software solutions/applications/capabilities or releases using approved COTS and GOTS software. The Contractor shall establish product baselines that configure approved COTS and GOTS software. The Contractor shall apply applicable SRGs and STIGs to the product baseline in accordance with accreditation guidelines.

The Contractor shall perform qualification testing to verify that COTS and GOTS software included in each release satisfies the release requirements, as defined in the functional requirements.

Software…