ATT 3 REBASE Final TO-2.pdf

Statement of Objectives

Expansion I

REBASE Task Order Number 0002

1 Background and Purpose

1.1 Background

1.2 Purpose

1.3 Scope

2 Objectives

2.1 Accelerate Multi-Domain Operations MS&A

2.2 Deliver MS&A Capabilities at the Speed of Relevance

3 Deliverables

4 Approach

4.1 Agile Leadership

4.2 Small Teams

4.3 Method

4.4 Schedule

4.5 Scoping

5 Resources

5.1 Government-Furnished Property or Equipment

5.2 Government-Furnished Information

5.3 Shared Infrastructure

5.4 Government Facilities

6 Technical Proposal Guidance

6.1 Cover Page

6.2 Executive Summary

6.3 General Approach

6.4 Accelerating Multi-Domain Operations MS&A

6.5 Delivering MS&A Capabilities at the Speed of Relevance

6.6 Staffing Approach and Qualifications

6.7 Page Count Summary

1 BACKGROUND AND PURPOSE

1.1 BACKGROUND

The Air Force Research Laboratory (AFRL) currently develops, maintains, and distributes the Advanced

Framework for Simulation, Integration, and Modeling (AFSIM), a modular, object-oriented Multi-Domain

Operations (MDO) Modeling, Simulation, & Analysis (MS&A) framework. AFRL intends for AFSIM to support multi-domain, multi-resolution MS&A activities ranging from engineering to mission-level into campaign. Beyond the framework itself, AFRL develops and maintains an extensive AFSIM-compatible toolset including applications to ease scenario and model creation, improve results visualization, and enhance operator-in/on-the-loop interactions.

Under the Redefining the Basic Analytical and Simulation Environment (REBASE) program, AFRL intends to use AFSIM to advance the state of the art in DoD MS&A and respond to the evolving needs of the defense innovation base as it accelerates the research, discovery, development, and transition of novel multi-domain warfighting capabilities.

Refer to the REBASE Basic Statement of Work for more information.

1.2 PURPOSE

This task order is the first in a series concerned with expanding the “boxset” capabilities delivered to end users in the form of AFSIM-compatible models, scenarios, and plugins. It will build upon the technical foundation provided by a common framework and shared development processes to accelerate the delivery of new features and capabilities to end users.

1.3 SCOPE

AFRL is soliciting proposals to advance the following REBASE objectives and initiatives:

1. Accelerate Multi-Domain Operations MS&A

a. Enhance Air Combat Operations Capabilities

b. Enhance Space Operations Capabilities

c. Enhance Cyber and EW Operations Capabilities

d. Expand Threat Representations

e. Expand Joint Operations Capabilities

2. Deliver MS&A Capabilities at the Speed of Relevance

a. Promote Agility and Disciple at Scale

1.3.1 Contract Period of Performance and Budget

The not to exceed ceiling for this effort will be $5M for a 12-month period of performance.

1.3.2 Contract Security Classification

This effort will require a level of facility security clearance (FCL) of TOP SECRET. An FCL is a determination made by the Government that a contractor is eligible for access to classified information.

It is a clearance of the business entity; it has nothing to do with the physical office structure.

This effort will require a level of safeguarding for classified information/material at the contractor’s facility of TOP SECRET.

It is anticipated that the work under this task order will be predominately SECRET and above. It is believed that the task order will require TOP SECRET work to be performed at the contractor’s facility.

1.3.3 Contract Place of Performance

Offerors may choose the location(s) from which to perform required development tasks. AFRL has provided offerors maximum flexibility to assemble high-quality, distributed teams while managing the risks typical of distributed development. Offerors should consult Section 5 for additional guidance and constraints.

2 OBJECTIVES

Offerors shall propose a disciplined approach to pursue each task order objective starting from the

REBASE Concept of Operation (CONOPS) and in-scope items from the REBASE Initial Product Backlog

(IPB). Task order objectives are directly traceable to in-scope REBASE objectives and initiatives by name.

While REBASE objectives and initiatives describe lofty, program-level ambitions, task order objectives attempt to moderate those ambitions within a finite period of performance and budget. AFRL has identified at least one task order objective per REBASE initiative. Figure-1 illustrates this concept.

Figure 1: Task Order Objectives

AFRL believes that these objectives are attainable under this task order’s period of performance and budget. AFRL also recognizes that the IPB is incomplete with respect to these objectives. The IPB is only a snapshot of the AFSIM Product Backlog at the time of solicitation. The AFSIM Product Backlog will continue to grow and change over the period of performance of this effort. As such, offerors should treat initial backlog items as a point of departure and illustrative of end-user needs, but not a complete story and certainly not a specification that supports development in isolation without open and frequent collaboration among all program stakeholders.

Likewise, the AFSIM Product Backlog contains (or will contain) items within the scope of this task order but not in the critical path of any task order objective. This does not mean that offerors should ignore these backlog items. It only means that these items are a lower priority than those in the critical path of a task order objective.

2.1 ACCELERATE MULTI-DOMAIN OPERATIONS MS&A

2.1.1 Task Order Objectives

2.1.1.1 By enhancing air combat operations...

AFRL desires that end users benefit from an expanded “out-of-the-box" air vehicle model catalog. By the end of this task order, AFSIM “out of the box" provides a more complete and readily configurable air vehicle model catalog of variable resolution.

More Complete: New air vehicle types and additional fidelity representations of existing air vehicle types have been added to the “out-of-the-box" model catalog. A model availability index

(e.g. the ratio of the number of air vehicle models users must develop on their own to the number of “out-of-the-box" models available to them, the lower the better) indicates expansion progress across releases.

Readily Configurable: Air vehicle models designed for end-user reconfiguration are accompanied by a min set of documentation, tests, and/or GUI tools. The time needed for an end user to reconfigure a low-fidelity model does not take more than 1 day. The time need for an end user to reconfigure a high-fidelity model does not take more than 5 days.

Variable Resolution: Models collectively support use cases ranging from constructive to virtual and war gaming for the purposes of performance, effectiveness, and military utility analysis.

AFRL desires that end users benefit from an expanded air combat tactics library and an enhanced behavior/tactic configuration and visualization toolset. By the end of this task order, AFSIM “out of the box" provides a more complete air combat behavior/tactics library and improved understanding of behaviors/tactics performance.

More Complete: New air combat behaviors/tactics have been added to the “out-of-the-box" behavior/tactic library. The additional behaviors/tactics cover a range of activities including basic flying control, relational maneuvering, and mission activities. A behavior/tactic availability index (e.g., the ratio of the number of tactics/behaviors users must develop on their own to the number of “out-of-the-box" tactics/behaviors available to them, the lower the better) indicates expansion progress across releases.

Improved Understanding: The AFSIM visualization toolkit supports real-time and post-processing visualization of behavior/tactic progress throughout a simulation. End users better understand the effects of behavior/tactic combinations on a simulation. All behaviors/tactics in “out-of-the-box" tactics/behaviors library are equipped to support visualization.

2.1.1.2 By enhancing space operations capabilities...

AFRL desires that end users – particularly, those less familiar with space operations but needing to assess effects on non-space technology concepts in a MDO context – benefit from an expanded space-asset boxset. By the end of this task order, AFSIM “out of the box" provides a more complete and readily employable space-asset library that supports end users with less experience in space operations.

More Complete: New space-asset models have been added to the AFSIM model library including space vehicles, space-based sensors, complete satellite constellations, and appropriate ground stations. A space capability availability index (e.g., the ratio of the number of space capabilities users develop on their own to the number of “out-of-the-box" capabilities available to them) indicates expansion progress across releases. As coordinated by the AFSIM Program/Product

Management Team (PMT), providers should plan to engage with stakeholders from the U.S.

Space Force to assist with prioritization of models for space operations.

Readily Employable: End users with limited familiarity with space operations are able to incorporate these space-asset models quickly into larger MDO scenarios.

Supports End Users: Space asset models are “plug-n-play" with supporting documentation, demos, and training material. Where possible, the user is prevented or warned away from implementing space systems or behaviors that are not physically realizable.

2.1.1.3 By expanding AFSIM’s cyber and EW operations capabilities...

AFRL desires that end users – particularly, those less familiar with cyber and electronic warfare (EW) operations but needing to assess effects on cyber-physical systems – benefit from boxsets where they can rapidly incorporate cyber and EW effects. By the end of this task order, AFSIM “out of the box" provides a more complete and readily employable library of cyber and EW effects that supports end users who have limited experience with these types of operations.

More Complete: Cyber effects modeling provides a richer representation of cyber operations, such as but not limited to representations of attack attribution, attack resources and pre-requisites, enhanced visualization of cyber effects propagation, and collection of cyber effects into probabilistic attack trees and fault trees. EW effects extend the currently available library of noise and deception techniques to support a richer interplay with sensor networks, such as but not limited to representations of electronic support measures, spinning/scanning sensors, and sensor and jammer resource management.

Readily Employable: New models of air, land, sea, and space assets include appropriate hooks to drop in cyber and EW effects. End users with limited familiarity of cyber and EW effects are able to incorporate these effects quickly into larger MDO scenarios.

Supports End Users: Cyber and EW effects are “plug-n-play" with supporting documentation, demos, and training material. Where possible, the user is prevented or warned away from implementing effects that are not physically realizable.

2.1.1.4 By expanding AFSIM’s threat representations...

AFRL desires that end users benefit from an expanded classified threat model boxset. By the end of this task order, AFSIM’s boxset provides a more complete classified threat model library by expanding the number of Intel-validated and native Intel-derived threat model representations, facilitated by a streamlined integration process.

More Complete: New threat models from third-party product lines as well as native AFSIM representations have been added to the AFSIM boxset. A threat model availability index (e.g., the ratio of the number of threat models users request to the “out-of-the-box" models available to them) indicates expansion progress across releases. Prioritization of new threat models is established by the AFSIM Threat and Scenario Working Group (TSWG).

Intel-Validated: Threat models produced directly by the Intelligence Community (IC). Focus is the Threat Modeling and Analysis Program (TMAP) product lines with supporting verification and validation (V&V) / provenance artifacts included.

Native Intel-Derived: Interpolated or extrapolated models of authoritative TMAP models implemented in an AFSIM format. Compared to integrated TMAP models, native models execute at least 2x faster, approximate performance within +/- 5%, and are accompanied by supporting V&V documentation showing traceability and relative performance characteristics.

Streamlined: Improved tooling and automated processes reduce TMAP model integration and native threat model development times to less than one week.

AFRL desires that end users benefit from an expanded classified threat scenario boxset. By the end of this task order, AFSIM’s boxset includes at least one additional IC-vetted classified threat scenario laydown with threat behavior profiles, facilitated by a streamlined integration process.

IC-Vetted: NASIC produced, simulation ready, threat scenario representations derived from

Office of the Secretary of Defense Defense Planning Guidance threat scenario laydown documents are imported/translated into an AFSIM format forming the basis for authoritative

AFSIM threat scenarios. Prioritization of threat scenario implementations is established by the

AFSIM TSWG.

Behavior Profiles: IC sourced threat behaviors, both individual and hierarchical, are included for all threat entities in the AFSIM threat scenario boxset.

Streamlined: Improved tooling and automated import processes reduce threat scenario development/import times to less than one month.

2.1.1.5 By expanding AFSIM’s joint operations capabilities…

AFRL desires that end users benefit from expanded “out-of-the-box" maritime and land operations model catalogs. By the end of this task order, AFSIM “out of the box" provides more complete maritime and land operations model catalogs that are natively instantiated, self-supporting, and of variable resolution.

Maritime: Primarily naval models spanning multiple asset categories including surface warfare assets, undersea warfare assets, and naval-based air and missile defense systems. As coordinated by the AFSIM PMT, providers should plan to engage with stakeholders from the U.S.

Navy and U.S. Marine Corps (USMC) to assist with prioritization of models for maritime operations.

Land Operations: Primarily army and special-forces models spanning asset categories including ground combat vehicles, aggregated troop movement, long-range precision/fires, and air/missile defense assets. As coordinated by the AFSIM PMT, providers should plan to engage with stakeholders from U.S. Army and USMC to assist with prioritization of models for land operations.

More Complete: Additional blue and red maritime and land operations models have been added to the “out-of-the-box" model catalog. A model availability index (e.g., the ratio of the number of maritime models users must develop on their own to the number of “out-of-the-box" models available to them, the lower the better) indicates expansion progress across releases.

Native: Models are preferably instantiated as native AFSIM models although mechanisms are in place to source authoritative maritime and land operations models into AFSIM when native instantiation is impractical or inefficient, principally for high-fidelity representations.

Self-Supporting: Models are accompanied by sufficient documentation, demos, and training material to enable analysts to incorporate them into MDO scenarios without support from the model development team.

Variable Resolution: Models collectively support use cases ranging from constructive to virtual and war gaming for the purposes of performance, effectiveness, and military utility analysis.

2.1.2 Point of Departure

Offerors shall use the REBASE CONOPS and any product backlog items identified under Section 2.1 of the

IPB as their technical point of departure to advance this objective.

2.1.3 Applicable Constraints and Resources

Offerors shall adhere to the general guidance enumerated under Section 4 and use resources enumerated in Section 5 in pursuit of this objective. Offerors shall also adhere to the following additional guidance specific to this objective.

2.1.3.1 Data Classification

Offerors should plan to develop model libraries at the lowest possible classification level using a modeling approach that readily supports extensibility at higher levels of classification.

o Offerors should use appropriate design tactics (e.g., stub functions or generic data) to support model extension at higher levels of classification.

o Offerors should understand sensitivities about critical technology areas and propose strategies to remind end users of their security obligations and safeguards to enforce proper use.

Offerors should plan to use authoritative data sources when configuring model libraries.

o Offerors should plan to configure unclassified models from unclassified DoD technical resources such as DoD Fact Sheets, Defense Technical Information Center reports, reputable scientific and engineering textbooks, or peer-reviewed publications.

o Offerors should plan to configure classified models using all applicable Security

Classification Guides (SCGs) obtained through appropriate channels.

o AFRL will facilitate interactions with technical experts and government programs to resolve ambiguity across applicable SCGs.

2.1.3.2 Data Pedigree

Offerors should align their technical approach to DoD modernization initiatives such as the

Digital Engineering Strategy and Model-Based Systems Engineering.

o Offerors should use modern, digital approaches to maintain traceability to authoritative data sources that provide end users with confidence in a model’s pedigree.

o Offerors should adopt data and metadata standards accepted and used across the DoD

MS&A community.

Offerors should propose strategies to remind end users of their ethical obligations when using authoritative data and safeguards to enforce proper use.

Offerors should propose strategies to identify and annotate where and why an analyst has modified the behavior of an authoritative model by supplying other data obtained through engineering knowledge or judgement.

AFRL will facilitate interactions with technical experts from other government programs to provide or review source data as required.

2.1.3.3 Community Coordination

Offerors should plan to engage with AFSIM working groups to help prioritize model library expansion as described in the REBASE CONOPS.

Offerors should propose strategies that avoid duplication of effort across the community, seek to address requirements gaps across existing investments, and improve the likelihood that community contributions can become part of the curated AFSIM “boxset.”

Offerors should plan to engage in the development of shared guidelines in the form of modeling standards and conventions that promote best practices for model organization, structure, and documentation.

2.1.4 Associated Deliverables

See Section 3 for a complete list of task order deliverables. AFRL has associated the following deliverables with this set of objectives:

Product: Requirements (A.1), Design Artifacts (A.2), Source Artifacts (A.3), Build System Artifacts

(A.4), Test Artifacts (A.5), Demonstration Artifacts (A.6), Documentation Artifacts (A.7)

Insight: Product Pages (C.2), Community Briefings (C.3)

2.2 DELIVER MS&A CAPABILITIES AT THE SPEED OF RELEVANCE

2.2.1 Task Order Objectives

By promoting agility and discipline at scale, AFRL desires that:

1. (Common Objective) All program stakeholders (sponsors, management, performers, and end users) benefit from greater transparency in AFSIM planning and development. Three months after task order kickoff, program stakeholders can provide continuous and timely input to the requirements driving AFSIM.

o Greater Transparency: Stakeholders do not need to ask the AFSIM PMT or development team(s) for insight into requirements driving development activities or the status of those activities.

o Continuous: Stakeholders can identify issues or suggest new features at any time. The time from stakeholder suggestion to capture in a visible backlog does not exceed two business days.

o Timely: Stakeholders can elaborate requirements prior to and during development as an incremental solution matures. Development teams consider all feedback.

2. (Common Objective) All program stakeholders benefit from a “shared-development” approach on REBASE. Six months after task order kickoff, REBASE has equipped all stakeholders to become productive contributors. External programs can reference authoritative guidance describing this approach for the acquisition of (or investment in) AFSIM-compatible products.

o Equipped: End users can adapt their own processes to conform to this approach.

o Productive: End-user contributions in the form of issues, requirements, or code require minimal rework to conform to authoritative guidance.

o Authoritative: All program stakeholders agree to and enforce normative practices. All task order products provide evidence of the consistent application of these practices.

2.2.2 Point of Departure

Offerors shall use the REBASE CONOPS as their technical point of departure to advance this objective.

2.2.3 Applicable Constraints and Resources

Offerors shall adhere to the general guidance enumerated under Section 4 and use resources enumerated in Section 5 in pursuit of this objective. Additionally:

Offerors shall plan to work in collaboration with other performers to achieve these objectives.

2.2.4 Associated Deliverables

See Section 3 for a complete list of task order deliverables. AFRL has associated the following deliverables with this set of objectives:

Process: Guidance Documentation (B.1), Process/Workflow Definitions (B.2), Executable

Processes/Workflows (B.3)

3 DELIVERABLES

Each item in the AFSIM Product Backlog should lead to a minimum-viable solution with sufficient technical and programmatic insight into its development. As described in the REBASE CONOPS, each program cycle provides an opportunity to elaborate and improve the process by which multiple teams contribute to AFSIM as a product. Table 1 lists the expected deliverables, frequency of delivery, and intended visibility on this task order. The deliverables are grouped into three categories: product

(solutions to items in the AFSIM Product Backlog; architecturally and stylistically conformant to AFSIM development and integration guidance, buildable, verifiable, documented, and readily demonstrated across targeted release branches), process (the systematic, reusable, and transferable approach to sustain AFSIM as a community-driven product), and insight (periodic technical and project status).

Continuous delivery reflects the nature of development on REBASE wherein teams are ensuring deliverables are always in a “shippable” state – available to the customer and end users.

Table 1: Deliverables

ID Deliverable Description Frequency Visibility Mapping A Product

A.1 Requirements User stories or other Agile requirements artifacts traceable to each AFSIM Product

Continuous Community CLIN Item

Backlog item and managed in a fashion visible to other program stakeholders

A.2 Design Artifacts Technical design or user-centered design artifacts such as UML diagrams, mock-ups, wireframes, workflow models, and derived technical requirements

Continuous Community CLIN Item

A.3 Source Artifacts Source code artifacts, input/script data, and resources conformant to AFSIM architecture and style guidance

Continuous Community CLIN Item

A.4 Build System

Artifacts

Build system (e.g., CMake, Jenkins) scripts that support Windows and Linux build environments as specified in the latest

AFSIM release

Continuous Community CLIN Item

A.5 Test Artifacts Automated unit and integration tests adhering to codebase testing conventions

Continuous Community CLIN Item

A.6 Demonstration

Artifacts

Validation scenarios accessible to end users from the Wizard “Demo Browser” that demonstrates the key features and capabilities described by an AFSIM Product

Backlog item

Continuous Community CLIN Item

A.7 Documentation

Artifacts

Buildable documentation (e.g., in the form of Restructured Text and source code comments) and other artifacts required for end-user training and support

Continuous Community CLIN Item

B Process

B.1 Guidance

Documentation Documentation required to get a new team of developers or modelers fully oriented to the accepted conventions, processes, and standards for contributing to the AFSIM codebase

Continuous Community CLIN Item

B.2 Process/

Workflow

Definitions

Detailed descriptions of development processes or workflows necessary to coordinate development activities across multiple teams and stakeholders

Continuous Community CLIN Item

B.3 Executable

Processes/

Workflows

The tool-specific configurations necessary to instantiate process/workflow descriptions on shared infrastructure

Continuous Community CLIN Item

C Insight

C.1 Business/

Financial Status

Project status reports providing execution and expenditure information for the last reporting period for the AFSIM PMT

Monthly AFRL A001

A002

A003

C.2 Product Pages Technical status information periodically updated to provide a synopsis of technical work planned and accomplished with links to relevant product and process artifacts

Continuous Community CLIN Item

C.3 Community

Briefings

Briefing materials to the AFSIM community Every Six

Months Community A004

4 APPROACH

Offerors shall propose a disciplined approach aligned with stated objectives, consistent with the REBASE

CONOPS, and suitable to investigate end-user needs such as those described in the IPB. The following sections provide additional guidance to help offerors craft a suitable approach.

4.1 AGILE LEADERSHIP

Offerors shall propose a technical leadership structure that can support small, cross-discipline teams.

Offerors shall appoint a Project Manager to oversee the execution of this task order.

4.2 SMALL TEAMS

Offerors shall propose an organizational structure composed of small, cross-discipline teams.

Offerors shall describe the number of teams, team composition, and each team member’s relevant skillset(s) that will contribute to each task order objective.

Offerors shall designate key members in each team that will operate within the larger “team-of-teams" coordination framework as described in the REBASE CONOPS.

o Offerors shall designate a Team Lead on each team.

o Offerors shall designate a Solution Architect on each team.

Offerors should propose team structures that adhere to a key tenet of Agile teams – that of full-time, dedicated team members. Deviation from this tenet introduces risk; offerors should justify their staffing approach accordingly.

Offerors should address key roles prescribed by chosen Agile frameworks or methodologies. For instance, teams that plan to adopt Scrum should identify a Scrum Master or explain the absence of that role.

Offerors may allocate project labor hours to an Agile “coach” or seasoned experts to improve performance outcomes. This provision does not extend to Agile training, large teams of consultants, or certification programs.

AFRL will identify complementary programmatic or technical interfaces as described in the

REBASE CONOPS and as resources permit.

4.3 METHOD

Offerors shall propose disciplined methods suitable for small teams developing complex software.

Offerors shall account for all program-level ceremonies described in the REBASE CONOPS.

Offerors should propose Agile frameworks, methodologies, and technical practices that will both complement and strengthen the "team-of-teams" coordination framework described in the

REBASE CONOPS.

Offerors should account for team ceremonies prescribed by a chosen framework or methodology. For instance, teams that plan to adopt Scrum should account for Sprint planning, reviews, and retrospectives in their approach or explain the absence of these ceremonies.

AFRL will provide critical representation at identified ceremonies as described in the REBASE

CONOPS and as resources permit.

4.4 SCHEDULE

Offerors shall adhere to predictable schedules that deliver incremental value at a sustainable pace.

Offerors shall align incremental delivery (Table 1) with the cadence described in the REBASE

CONOPS.

o Offerors shall assume a program cycle length of 12 weeks for the duration of this effort.

o Where offerors plan to use an iterative development cycle to manage work in progress:

Offerors should assume an initial development iteration length of 4 weeks.

Offerors may plan to adjust the length of an iteration in coordination with AFRL.

Offerors shall plan a task order kickoff meeting within 15 days after receipt of order (ARO).

Offerors should plan to participate in a program kickoff meeting within 30 days ARO.

Offerors should assume the first program cycle starting within 15 days after program kickoff.

Offerors should identify any major milestones or decision points.

4.5 SCOPING

Offerors shall adopt a flexible approach to requirements that leaves room for innovation and discovery.

Offerors shall plan to coordinate with program stakeholders (to include other performers) under structured ceremonies to refine and prioritize requirements in the AFSIM Product Backlog.

o Offerors should use such ceremonies to identify the subset of features likely to comprise minimum-viable solutions for the AFSIM community.

o Offerors should use such ceremonies to establish acceptance criteria (i.e., a working

“definition of done”) and time estimates for backlog items prior to development.

o Offerors should identify any assumptions about stakeholder inputs.

Offerors should adopt a consistent approach to identify, capture, and refine requirements driving solutions. Typical forms include user stories, use cases, or usage scenarios captured at various degrees of detail (e.g., feature, story, or task).

Offerors are encouraged to propose novel user-centered design approaches to drive requirements discovery and validation through early proofs of concept or prototyping.

Offerors are encouraged to propose innovative ways to elicit end-user feedback from the broader AFSIM community without requiring AFRL to broker or coordinate these exchanges.

5 RESOURCES

Offerors should consider Government-provided resources during proposal development and planning.

5.1 GOVERNMENT-FURNISHED PROPERTY OR EQUIPMENT

Under REBASE, AFRL will not transfer any Government-furnished property or equipment. AFRL plans to leverage other AFRL and DoD-hosted platforms and services to establish a shared development environment that can facilitate coordination between program performers as described in Section 5.3.

5.2 GOVERNMENT-FURNISHED INFORMATION

Offerors shall incorporate Government-furnished information (GFI) into their proposal to the maximum extent possible. The primary outputs of this effort (AFSIM – the product and the processes necessary to develop it) will become cost-saving GFI on future task orders and other DoD-funded efforts.

ID Item Description Location Availability A Product Artifacts Requirements, designs, source code, build system artifacts, test artifacts, demonstration scenarios, and documentation associated with AFSIM

AFSIM Portal on DI2E

Solicitation

A.1 Initial Product Backlog A snapshot of the AFSIM Product Backlog at the time of solicitation

By Request Solicitation

B Process Artifacts Development process definitions, executable workflows, and related guidance applicable to the broader AFSIM community

AFSIM Portal on DI2E

Solicitation

B.1 REBASE CONOPS An initial sketch of the development processes or workflows suitable to coordinate development activities across multiple teams and stakeholders

By Request Solicitation

5.3 SHARED INFRASTRUCTURE

Offerors shall use shared infrastructure to promote shared development and coordination at scale.

AFRL will provision space on shared, unclassified infrastructure for performers to manage all community-visible products necessary for coordination and as identified in Section 3.

o Offerors may assume a basic provisioned environment on DI2E to include issue backlogs, task boards suitable for Scrum or Kanban, wiki pages, and git repositories.

o Offerors may identify additional tools or capabilities beyond those in the basic provisioned environment; AFRL can make no guarantees on their availability or suitability.

AFRL will pursue a similar shared solution for management and visibility into classified products necessary for coordination and as identified in Section 3.

o AFRL plans to work with performers to secure access to the VISiON network.

o Offerors should not assume the availability of VISiON during contract performance.

Offerors shall plan to provide continuous visibility into each team’s development progress on shared infrastructure as described in the REBASE CONOPS.

o Offerors shall plan to maintain Product Pages to provide essential development visibility.

o Offerors should plan to use their Product Pages to convey essential status information such as goals, assumptions, associated user stories or requirements (backlog), schedule

(roadmap), targeted releases, and links to other relevant technical information.

Offerors shall plan to maintain implementation artifacts on shared infrastructure in accordance with evolving repository conventions and organizational standards.

Offerors should plan for distributed teams using virtual collaboration tools appropriate to protect Controlled Unclassified Information – specifically, Controlled Technical Information (CTI) and export-controlled (ITAR) information.

o AFRL has limited virtual collaboration capabilities (e.g., virtual teleconference with audio and screen sharing) accessible to external contractors that also meet these constraints.

o AFRL will continue to pursue approved solutions that can also become shared infrastructure under this effort.

Offerors may choose to leverage their own development infrastructure and tools as long as they also mirror community-visible information on shared infrastructure in accordance with the

REBASE CONOPS.

5.4 GOVERNMENT FACILITIES

The vast majority of the work performed under REBASE will occur at contractor facilities. AFRL may provide up to ten office spaces at WPAFB for use under REBASE. Offerors may propose to use a portion of this Government-provided office space, but are not required to do so. If offerors propose to use

Government-provided office space, they shall identify the number of individuals, the percentage of time those individuals will need to work on base, and the purpose of that work.

6 TECHNICAL PROPOSAL GUIDANCE

This section provides an outline and notional guidance specific to each aspect of the technical proposal.

AFRL recommends that offerors adhere to this outline to streamline proposal development, evaluation, and negotiation. Offerors should interpret all guidance provided in this section as recommendations, not requirements, for the technical proposal.

Offerors should submit a technical proposal describing their technical approach, staffing approach, and relevant experience and qualifications. In the technical proposal, offerors should first introduce their general technical approach, and then describe their specific approach to pursue each of the task order objectives, and finally establish the qualifications of the team that will perform the work.

6.1 COVER PAGE

The technical proposal should include a cover page that provides the following information:

a. A proposal title such as “A Technical Proposal for REBASE Task Order Number 0002”

b. Technical and contractual points of contact

c. A proprietary data disclosure statement, if the proposal includes proprietary information

6.2 EXECUTIVE SUMMARY

Offerors should provide an executive summary for their technical proposal not to exceed one (1) page.

6.3 GENERAL APPROACH

Offerors should limit discussion on their general technical approach to three (3) pages. This section should convey a coherent understanding of AFRL’s overall objectives under REBASE executed through this task order. While general in nature, this section should avoid straying into general philosophies of modeling and analysis or agile software development.

6.4 ACCELERATING MULTI-DOMAIN OPERATIONS MS&A

Offerors should limit discussion on their specific approach to pursue objectives to ten (10) pages. This section should describe how offerors plan to reach objectives starting from a common point of departure while adhering to applicable constraints, leveraging provided resources, and addressing anticipated challenges.

Offerors should also establish technical credibility to address objectives by selecting up to three (3) in-scope items from the IPB and proposing a viable approach to investigate and implement a minimum-viable solution for each item. Offerors should generally limit their discussion to two (2) pages per item.

6.4.1 A solution for [e.g., Users to compose air combat behaviors and tactics]

As an example, an offeror might select the epic “Users can compose air combat behaviors and tactics” from the IPB. This section would tell a story about how a team would approach this epic if it appeared in the AFSIM Product Backlog. This story ought to convey a baseline understanding of the featured user(s), their anticipated needs and challenges, and a plan to investigate these unique concerns through a disciplined approach. The description of this approach ought to provide confidence that the offeror’s team can skillfully navigate the problem space to arrive at a variety of creative solutions.

Offerors might also state initial assumptions or hypothesize potential solutions in the form of conceptual designs or models of a user’s work or tools reimagined. Given the focus on end-user needs, offerors might describe how they plan to draw in the necessary subject matter expertise to help understand and validate those needs in collaboration with an appointed Product Owner.

6.4.2 A solution for […]

This section would address the next chosen backlog item in the same manner as the preceding section.

6.4.3 A solution for […]

This section would address the next chosen backlog item in the same manner as the preceding section.

6.5 DELIVERING MS&A CAPABILITIES AT THE SPEED OF RELEVANCE

Offerors should limit discussion on their specific approach to pursue objectives to four (4) pages. This section should describe how offerors plan to reach objectives starting from a common point of departure while adhering to applicable constraints, leveraging provided resources, and addressing anticipated challenges.

6.6 STAFFING APPROACH AND QUALIFICATIONS

In this section, offerors should establish their unique qualifications to pursue all task order objectives by introducing their team and citing relevant past performance.

6.6.1 Organization

Offerors should propose an initial organizational structure, identify the number of teams, and describe the focus of each team aligned with task order objectives. Offerors should ensure that this structure is consistent with the “team-of-teams" coordination framework described in the REBASE CONOPS and other applicable guidance in Section 4. Offerors should also identify principal technical leadership roles similar to the following table. Offerors should limit this discussion to two (2) pages.

Technical Leadership

Name Principal Role Skillset Company

[Name] Project Manager* e.g., Technical leadership

Team building

Customer relations

Risk management e.g., Prime, Inc.

[Name] […] […] […]

*Note: Offerors should summarize the qualifications of each principal team member in Section 6.6.5

6.6.2 Resources

Offerors should describe facilities or infrastructure planned for use in the execution of this effort to include relevant accreditation details. Offerors should also identify whether and how they plan to use

Government-provided office space as described in Section 5.4. Offerors should limit this discussion to two (2) pages.

6.6.3 Teams

For each team identified in the previous section, offerors should identify principal members by role such as a Team Lead and Solution Architect (Section 4). Offerors should also identify relevant skillsets that will contribute to a balanced team. Offerors should limit this discussion to one (1) page per team.

6.6.3.1 (e.g., Visualization and Post-Processing) Team

As an example, an offeror might identify one team to build or enhance visualization and post-processing tools. This section would describe the currency, quality, depth of experience, and unique qualifications of the team. It would also provide a team roster that describes the team composition by role and skillset similar to the following table. This roster should include any subcontractors as integral members of the team and identify any supporting roles that will improve team success.

Visualization and Post-Processing Team

Team Members

Name Role(s) Skillset Company

[Name] Team Lead*

Senior Software Engineer

3D Visualization C++ Development e.g., Prime, Inc.

[Name] Solution Architect*

UX Engineer

Interaction Design User Analysis e.g., Subcontractor, Inc.

Supporting Cast (External to Team)

[Name] Proxy End User (Analysis SME) Operations Analysis Data Analytics e.g., Subcontractor, Inc.

*Note: Offerors should summarize the qualifications of each principal team member in Section 6.6.5

6.6.3.2 […] Team

This section would address the next team in the same manner as the preceding section. Add additional sections as required.

6.6.4 Portfolio

Offerors should describe prior work that emphasizes similar experience and past performance. Offerors should limit a description of their portfolio to one (1) page per team. Offerors who propose multiple teams should clearly indicate which projects or works cited pertain to each team. Offerors should avoid statements about “corporate performance” and should not attribute “corporate performance” to individuals and teams that did not actually perform the work. Offerors should provide a government point of contact for any project developed on a government contract.

6.6.5 Personnel Qualifications

Offerors should summarize the experience, qualifications, and skills of principal team members proposed on this task order. Offerors should limit the length of this section to approximately a half (0.5) page per principal team member.

6.7 PAGE COUNT SUMMARY

Technical Proposal Section Recommended Page Limits

Executive Summary 1 page

General Approach 3 pages

Accelerating Multi-Domain Operations MS&A 10 pages

Delivering MS&A Capabilities at the Speed of Relevance 4 pages

Staffing Approach and Qualifications

Organization 2 pages

Resources 2 pages

Teams 1 page per team

Portfolio 1 page per team

Personnel Qualifications 0.5 pages per principal team member