ATT 2 REBASE Final TO-1.pdf

Statement of Objectives

Foundation I

REBASE Task Order Number 0001

1 Background and Purpose

1.1 Background

1.2 Purpose

1.3 Scope

2 Objectives

2.1 Evolve Foundational MS&A Frameworks and Tools

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 Evolving Foundational MS&A Frameworks and Tools

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

AFRL’s ability to broadly solicit and acquire new AFSIM-compatible models, scenarios, and plugins depends upon a stable architecture and technical foundation. This task order is the first in a series concerned with advancing the capabilities of a common framework used by a growing pool of potential contributors. It will also establish essential development processes and tooling necessary to orchestrate technical efforts and 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. Evolve Foundational MS&A Frameworks and Tools

a. Enrich Multi-Domain Foundations

b. Join the Digital Ecosystem

c. Improve the User Experience

d. Promote Flexibility in Use

e. Leverage Computation at Scale

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

a. Promote Agility and Disciple at Scale

b. Build the Software Factory

c. Scale Content Delivery and Operations

1.3.1 Contract Period of Performance and Budget

The not to exceed ceiling for this effort will be $9M for a 15-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 SECRET.

It is anticipated that the work under this task order will be predominately unclassified. It is believed that the task order will require some collateral SECRET work to be performed at the contractor’s facility. It is believed that a few personnel will require TOP SECRET clearances to participate in relevant coordination activities.

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

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.

Figure 1: Task Order Objectives

2.1 EVOLVE FOUNDATIONAL MS&A FRAMEWORKS AND TOOLS

2.1.1 Task Order Objectives

2.1.1.1. By enriching AFSIM’s multi-domain foundations...

AFRL desires that program stakeholders – particularly, capability providers and end users – benefit from improvements to core simulation framework elements (i.e., the World Simulation Framework or WSF).

By the end of this task order, AFSIM provides a more complete and stable simulation framework that improves the quality of “boxset” models built from its elemental components and services.

More Complete: An essential subset of WSF services and components can readily support new multi-domain expansion requirements. An Expansion Support Index (e.g., the ratio of new

“boxset” models that do not require core addition/modification to the total number of “boxset” models) indicates trending improvement across releases.

More Stable: Core enhancements do not introduce breaking changes to “userspace” (i.e., scripted) model assets within a major release cycle. A relative Framework Maturity Index (e.g., the ratio of unchanged core modules to the total number core modules) indicates trending stability across releases.

Improves Quality: Test suites provide evidence of the functional correctness of core simulation framework services and components using suitable test coverage criteria. Capability providers can freely compose framework elements to specify system or system-of-systems models of consistent fidelity and abstraction.

2.1.1.2. By joining AFSIM to the digital ecosystem…

AFRL desires that program stakeholders – particularly, capability providers and end users – benefit from more standards-compliant interoperability options. By the end of this task order, AFSIM extends native support for Distributed Interactive Simulation (DIS) v7 and the latest major version of the Universal

Command and Control Interface (UCI) and Open Mission Systems (OMS) standards.

Extends Support: AFSIM incrementally extends support for each standard in accordance with priorities established by end users and as reflected in the AFSIM Product backlog. Each release provides end users with evidence of incremental progress towards standards-compliant interoperability.

Native: AFSIM provides a DIS implementation with full source code that end users can modify or extend to address their own unique simulation interoperability needs. End users can also replace this native DIS implementation with a commercial interoperability solution (e.g., application middleware or API). In a similar fashion, AFSIM uses a full-source government reference CAL (Critical Abstraction Layer) to support OMS/UCI but also supports replacement with other OMS-compliant vendor solutions.

2.1.1.3. By improving the user experience…

AFRL desires that end users – particularly, analysts and their supporting developers – benefit from investments in AFSIM’s baseline tool suite to include Wizard, Warlock, Results Visualization, and auxiliary applications like Mover Creator. By the end of this task order, these investments culminate in a simpler, more intuitive, and versatile tool suite for MDO scenario authoring, execution, and analysis.

Simpler: Investments streamline analyst workflows and automate common data manipulation and management tasks characteristic of mission effectiveness analyses. An Analyst Productivity

Benchmark Index (e.g., a composite index that includes measures for task efficiency, effectiveness, and overall user satisfaction) can guide specific investment decisions and design options.

More Intuitive: A consistent “look and feel” across applications matches end-user expectations and mental models as validated through early and continuous end-user feedback.

Versatile: Developers – particularly those supporting analysts as capability providers – can readily extend AFSIM’s baseline tool suite for domain-specific applications. Domain-specific extensions can introduce new model types and attributes without requiring updates to shared syntax files or schemas. These extensions can also reuse primitive user-interface elements and patterns to support unique analytical perspectives without requiring new user-interface code.

2.1.1.4. By promoting flexibility in use…

AFRL desires that program stakeholders – particularly, capability providers and end users – benefit from a framework that natively supports a multi-resolution modeling approach. Nine months after task order kickoff, these stakeholders have a minimum set of language and tool features necessary to build and verify models of variable resolution.

Natively Supports: End users can specify multi-resolution models using elemental framework components and services. The solution does not require distributed/federated applications.

Minimum Set: There are several technical approaches that can fulfill this objective. This objective emphasizes a minimum-viable solution that can elicit feedback from other program stakeholders and end users. It is not a comprehensive solution.

Nine Months: There is still time in the task order to either commit to the solution with additional features or pivot towards a different approach.

Build and Verify: End users can specify models that support multiple levels of resolution or fidelity and provide evidence that these models provide consistent results.

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

2.1.1.5. By preparing AFSIM to leverage computation at scale…

AFRL desires that program stakeholders – particularly, capability providers and end users, benefit from a concerted effort to benchmark and improve core simulation framework performance. By the end of this task order, AFSIM provides a performance baseline across a variety of workloads that supports end-user optimization goals.

End-User Goals: Performance measures (e.g., throughput, capacity, scalability, resource usage, etc.) are relevant and performance targets are meaningful to program stakeholders. Capability providers and end users can focus optimization efforts on value-added models, scenarios, and plugins and avoid troubleshooting framework plumbing.

Concerted: An AFSIM Performance Benchmark Index guides specific architectural investments to remediate regressions or provide incremental performance improvement.

Baseline: Benchmark tests cover all relevant framework components and services that affect performance targets. Program stakeholders can monitor deviation from this baseline without having to rerun benchmark tests.

Workload Variety: Benchmark tests cover both distributed and single-process execution characteristic of both desktop and scale processing use cases. Workloads anticipate the growing use of AFSIM alongside cloud-native applications.

2.1.2 Point of Departure

Offerors shall use the REBASE CONOPS and any product backlog items identified under Section 2.2 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. Additionally:

Offerors shall appoint a Principal Architect to fulfill a critical program-level role that will integrate technical efforts that implicate foundational MS&A frameworks and tools as described in the REBASE CONOPS.

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

2.2.1.1. 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 Program/Product

Management Team (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.1.2. By investing in a software factory...

AFRL desires that all program stakeholders benefit from a continuous delivery model realized through investments in DevSecOps practices and software pipelines. Nine months after task order kickoff, all program stakeholders can work together at a sustainable pace and release products “on demand” to satisfy diverse stakeholder groups and multiple security environments.

Work Together: Software pipelines enforce a “shared-development” approach through continuous tool-based integration and inspection. Framework developers, capability providers, and end users can all contribute to a shared codebase with configuration safeguards and basic quality gates in place.

Sustainable Pace: All program stakeholders can maintain the program-level cadence described in the REBASE CONOPS while improving development efficiency. An Average Cycle Time Metric

(e.g., the rolling average of time to move a backlog item from "selected for development” to

"ready to release”) indicates trending improvement.

Diverse Stakeholder Groups: Software pipelines support multiple product lines tailored for different stakeholder groups as described in the REBASE CONOPS. At a minimum, the software factory produces unclassified US-Only and FVEY/TTCP-Export variants as well as classified variants that include collateral Secret data sets. The software factory also supports both “latest” and “stable” product lines across both unclassified and classified variants. Lastly, the software factory directly supports downstream pipelines maintained on above-Secret networks.

Release on Demand: A “shippable” version of AFSIM always exists across all product variants.

The AFSIM PMT, as release authority, has sufficient information to determine readiness to release at any time. Quality metrics, such as a Pre-Release Defect Density Estimate (e.g., a proxy metric obtained through continuous tool-based inspection or analysis and historical defect tracking), begin to support all release authority decisions.

Multiple Security Environments: Application security compliance checking and automation support maintenance of software certification on the Air Force Evaluated Products List (EPL) and

Air Force Intelligence Community Approved Products List (APL). The software factory produces evidence that can streamline approval and use of AFSIM across DoD information networks to include, at a minimum, NIPR, DREN, SIPR, SDREN, and JWICS.

2.2.1.3. By scaling content delivery and operations…

AFRL desires that program stakeholders – especially, end users – benefit from investments that improve the availability of new AFSIM content and capabilities. By the end of this task order, end users have on-demand access to new content and capabilities supported by both traditional and just-in-time learning models.

On Demand: Both unclassified and classified content delivery networks provide direct, digital access to nightly builds and new releases. The time delay between the availability of a new unclassified release and its corresponding classified release shrinks by 50% (e.g., two weeks instead of one month). The quantity of physical media necessary to transfer a classified release to users without digital access reduces by 50% (e.g., 4 discs instead of 8 discs).

Traditional Learning: Users can register for periodic in-person or virtual learning events – up to

15 opportunities per year. Up to 24 students can register for each event with a 12:1 student-to-instructor ratio.

Just-in-Time Learning: Support products such as documentation and end-user training provide access to relevant knowledge when and where required. Support products improve coverage of existing and new AFSIM features with 100% coverage of features through basic documentation and improved coverage of features through self-paced training modules or tutorials. A virtual helpdesk provides responses to user inquiries within two business days and end-user questions drive updates to support products.

2.2.2 Point of Departure

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

IPB 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 lead program-level collaboration necessary to meet objectives under the shared initiative: “Promote Agility and Discipline at Scale (Section 2.2.1.1).”

o Offerors should consider the adequacy of shared infrastructure (Section 5.3) to address program-level collaboration needs.

o Offerors should promote the use of virtual collaboration events to the maximum extent possible.

Offerors shall appoint a Release Engineer to fulfill a critical program-level role accountable for continuous-delivery pipelines and associated quality-assurance activities as described in the

REBASE CONOPS.

Offerors shall appoint an Operations Lead to fulfill a critical program-level role that will orchestrate technical efforts through program-level ceremonies and end-user support activities as described in the REBASE CONOPS.

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:

Product: Requirements (A.1), Build System Artifacts (A.4), Test Artifacts (A.5), Documentation

Artifacts (A.7)

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

Processes/Workflows (B.3)

Insight: Product Pages (C.2), Community Briefings (C.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

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

Continuous Community CLIN Item

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 appoint a Project Manager to oversee the execution of this task order.

Offerors shall appoint a Principal Architect to fulfill a critical program-level role that will integrate technical efforts that implicate foundational MS&A frameworks and tools as described in the REBASE CONOPS.

Offerors shall appoint a Release Engineer to fulfill a critical program-level role accountable for continuous-delivery pipelines and associated quality-assurance activities as described in the

REBASE CONOPS.

Offerors shall appoint an Operations Lead to fulfill a critical program-level role that will orchestrate technical efforts through program-level ceremonies and end-user support activities as described in the REBASE CONOPS.

4.2 SMALL TEAMS

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

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

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 lead 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 0001”

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 EVOLVING FOUNDATIONAL MS&A FRAMEWORKS AND TOOLS

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 perform round-trip engineering and analysis]

As an example, an offeror might select the epic “Users can perform round-trip engineering and analysis” 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/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 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 their credibility to provide technical leadership and fulfill a critical orchestration and integration role on this task order. Offerors should establish this credibility by describing their planned approach to bring a general concept of operations into reality. Offerors should reserve discussions on general experience and qualifications to Section 6.6.

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] Principal Architect* […] […]

[Name] Release Engineer* […] […]

[Name] Operations Lead* […] […]

[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

Evolving Foundational MS&A Frameworks and Tools 10 pages

Delivering MS&A Capabilities at the Speed of Relevance 10 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