FMT RFP Attachment 03 Common Core CM Process v4.4.pdf

23 FEB 2024

Version 4.4

Distribution Statement A. Approved for public release: distribution is unlimited.

Common Core (CC)

Configuration Management (CM)

Process

Prepared by

U.S. Army Program Executive Office Simulation, Training, and Instrumentation (PEO STRI)

PD Virtual Training Systems (PD VTS)

Family of Maintenance Trainers Product Line (FMT PL)

REVISION HISTORY

Revision Number

Date Log of Changes Made and Change Description/Rational

4.1 11 APR 23 Initial Formal Release

4.2 28 APR 23 • Added title page, revision history, and table of contents.

• Revised Paragraph 6, CCB Voting, to allow CCB Chairperson to approve change to proceed if no other voting members are present and the change does not impact requirements or cost.

This change is also reflected in Figure 1.

• Added “New Feature” and “Bug Fix / Correction” as options for Category in Table 2, Common Core Roadmap Data Items.

• Added description for the solution presentation in Paragraph 4, Configuration Control Board, to identify the items that need to be presented.

4.3 10 MAY 23 • Revised status data item from “Pending Baseline Integration” to “Baseline Integration and Test”

• Revised Paragraph 6, CCB Voting, second bullet, from “integration” to “integration and test”

• Revised Figure 1 flowchart to include missing CC Roadmap status change from “Pending Solution Development” to “Solution Development”

4.4 23 FEB 24 • Title page - Removed “Mission Support” and “MS” from PD VTS

• Paragraph 3 – Clarified timeline for change request submission to

CCB discussion. Minimum of one week is required to receive and process change request prior to CCB.

• Paragraph 5 – Added language to describe prioritization of changes

• Paragraph 7 – Clarified that funding must be provided for changes needed to support platform mission requirements

Table of Contents

1. Background

2. Common Core Change Identification

3. Change Request Submission

4. Configuration Control Board (CCB)

5. Change Integration

6. CCB Voting

7. Funding

1. Background The Common Core (CC) is the common hardware and software baseline that provides the infrastructure, functionality, and capabilities to support maintenance training of legacy and future military platforms across the FMT Product Line (FMT PL) of Diagnostic Troubleshooting Trainers (DTT), Part Task Trainers (PTT), and Hands On Trainers (HOT). As the FMT PL grows to incorporate additional military platforms and products there is a need for formal configuration control of the CC to ensure changes to the CC baseline are appropriately assessed, approved, funded, integrated, and tested prior to release for use across the FMT PL.

2. Common Core Change Identification A change to the CC is identified by a user, stakeholder, contractor, or other Government personnel. The identifier completes the Change Request form including the Change Description, the Benefit/Rationale for the change, need-by date, the recommended priority for incorporation of the change into the CC Baseline, point of contact information, and requesting entity name as described in Table 1 below.

3. Change Request Submission The change identifier submits the Change Request form via email to the PEO STRI CC POCs. All requests must be submitted to the primary and secondary PEO STRI CC POCs. The PEO STRI CC POC confirms receipt and provides the request to the PEO STRI CC Team for initial review. If the Change Request is determined to be acceptable for CCB review by the PEO STRI CC Team, the PEO STRI CC POC updates the CC Roadmap with initial change request data, assigns a unique identification (ID) number to the change, and sets the status of the change to “Pending CCB Review”. If necessary, the PEO STRI CC POC will reach out to the change requestor for more information and/or clarification of the change request. Change requests received less than one

(1) week from the next scheduled CCB will be discussed at the following CCB.

4. Configuration Control Board (CCB) On a bi-weekly basis, the CCB members, as described in Table 2 below, convene at a Working Group (WG) to review change requests. The PEO STRI POC will provide a CCB agenda and slide deck detailing changes to be discussed to the CCB members no less than three (3) business day prior to the WG. During the WG the requestor presents the change request and rationale to the CCB. The CCB discusses the change and completes the remainder of the necessary information for the change in the Common Core Roadmap as described in Table 2 below. The PEO STRI CC POC updates the status of the change to “Impact Assessment”. The PEO STRI Product Teams and associated product contractors then evaluate the change against their product to determine any cost, schedule, or performance impacts from the change. At a subsequent bi-weekly WG (determined by the CCB based on change scale), the PEO STRI Product Teams and associated product contractors discuss impacts to their product caused by the change. Impact assessments must be provided by all FMT Product Line PEO STRI Product Teams; negative responses are required. Following presentation of impacts, the CC Roadmap data for the Change Request is finalized by the CCB and CCB Chairperson. If the change request impacts requirements, the requirements owners will then determine if the change request is an approved requirement for training. If the change is not approved as a requirement and the change is still desired, the CCB will discuss the change in order to reach a consensus. If the change is no longer desired, the PEO STRI CC POC updates the status of the change to “Cancelled” and the change is closed. If the change is approved as a requirement and there are cost impacts identified, the change discussion is tabled for a subsequent WG at which time the Platform PM’s can attend to discuss funding the change. At the conclusion of discussions and after securing funding commitment (if necessary), the voting members of the CCB vote to allow the change request to proceed to solution development. If the change is voted down, the requestor must revise the change request or accept the rejection. If the requestor wishes to revise the request to adjudicate concerns from the CCB, the PEO STRI CC POC updates the status of the change to “Pending Revision” and the review process begins again at the next bi-weekly WG. If the rejection is accepted, the PEO STRI CC POC updates the status of the change to “Rejected” and the change is closed. If the change is approved to proceed to solution development, the PEO STRI CC POC updates the status of the change to “Pending Solution Development”. If the change’s Need-By date is prior to the next scheduled annual release date or if the CCB identifies the change as an immediate need, the change is deemed urgent and the PEO STRI CC POC updates the status of the change to “Solution Development” and the CC Contractor begins work on developing a solution to implement the change immediately. For example, a change that is required to meet DoD Cybersecurity requirements with a suspense date prior to the next scheduled CC annual release date. Another example would be if a product team need a change in order to meet a mission requirement for a delivery scheduled prior to the next scheduled CC annual release date. If the change is not urgent, the change is queued for solution development and incorporation via the appropriate annual release cycle in order to meet the Need-By date for the change. For non-urgent changes, at the appropriate time, the PEO STRI CC POC updates the status of the change to “Solution Development” and the CC Contractor begins work on developing a solution to implement the change.

Once the change moves forward into Solution Development and the CC Contractor has identified and designed a solution for the change, the CC Contractor presents the change solution at the bi-weekly WG. The CC Contractor’s change solution presentation shall include identification of the bug cause (if the change is a bug fix), the proposed solution to implement the change or fix the bug, and the high-level test plan for the solution (to facilitate any coordination necessary). If possible, the CC Contractor may also demonstrate the solution. The CCB will evaluate the solution presented and voting members will vote to allow the change solution to proceed to integration into the CC Baseline. If the change solution is voted down, the CCB must determine if the change is still desired. If the change is no longer desired, the PEO STRI CC POC updates the status of the change to “Cancelled” and the change is closed. If the change is still desired, the CC Contractor must revise the solution to address concerns from the CCB and present a revised solution at the bi-weekly WG. If the change solution is approved, the PEO STRI CC POC updates the status of the change to “Baseline Integration & Test”.

After the change solution is integrated into the baseline and installed onto the CC Contractor’s Systems Integration Lab (SIL), the Government conducts formal testing of the new baseline to ensure the integrated change solution meets performance specifications for FMT Product Line and has not caused any degradations to training. If deficiencies are found, the CC Contractor shall address the deficiencies and retest with the Government until all deficiencies are resolved and the Government concurs all tests have been passed. The test results are then presented to the CCB. The CCB votes to approve release of the updated baseline. If the update is to Software, the CC Contractor releases the update to the requesting PEO STRI Product Team for use in development of specific products/solutions, to the PEO STRI CC Team for annual releases, or to both for urgent changes. If the Software update is for use in development of specific products/solutions, the requesting platform will utilize a deviated branch baseline until the next subsequent annual release at which time the change is fielded to all FMT Product Line devices.

For annual releases, the PEO STRI CC Team will coordinate with and provide the software update to PEO STRI Project Lead Training Aids, Devices, Simulators, and Simulations (TADSS) Support Operations (PL TSO) for distribution to the field. For urgent releases, the PEO STRI CC Team will coordinate with and provide the software update to both PEO STRI PL TSO and to PEO STRI Product Teams for immediate use. If the update is to hardware, the approved design is released to the PEO STRI Product Teams where incorporation of the approved design is planned into the tech refresh cycle for specific products or for immediate incorporation for urgent changes, as necessary.

5. Change Integration CCB approved changes to the CC Software made by the CC Contractor to meet immediate mission requirements create branches from the main baseline, however integration of these changes along with pre-planned CCB approved changes to the main CC Baseline will occur on an annual basis and be released to all CC products for baseline synchronization.

CCB approved changes will be placed into a living queue based on change priority. The priority of the change is approved by the CCB. The CCB may reprioritize the change queue as necessary with consensus agreed upon by the CCB members.

CC Hardware changes approved through the CCB process update the CC Hardware baseline design. Products which utilize the CC HW baseline must plan to update Product baselines at their next subsequent Tech Refresh.

6. CCB Voting CCB voting members are listed in Table 2 below. There are three checkpoints throughout the change process at which the CCB will conduct a vote to proceed to the next phase. These checkpoints are:

• Vote to proceed with solution development

• Vote to approve the proposed solution to proceed to baseline integration and test

• Vote to proceed with release of the integrated baseline

In order for a change to proceed through each voting checkpoint, a 2/3 majority must be achieved.

Requirements Owners and Platform PMs will hold voting authority. Each platform will be allotted one vote shared between the Requirements Owners and Platform PMs for each platform. In the event no other voting members are present and there are no impacts to requirements or cost, the CCB Chairperson may approve the change to proceed through a voting checkpoint.

7. Funding For a change to proceed from the change proposal review phase to solution development phase, funding may need to be available and provided. For changes needed to meet immediate platform mission requirements, funding must be provided. Changes that are for common benefit, cybersecurity, or minor in nature will be incorporated through the annual Common Core improvement tasks of the Common Core Contractor.

Change Request Input Data Items Data Item Description Provided

By Reviewed By

Change Description Brief description of the change. Requestor PEO STRI CC POC Benefit/Rationale Brief description of the benefit of the change Requestor PEO STRI CC POC

Need-By Date Date by which the change needs to be released for use.

Requestor PEO STRI CC POC

Priority Recommended rating of High, Medium, or Low representative of the urgency of the change.

High: Change is needed as soon as can be available.

Medium: Change is needed within 1-2 years incorporated through annual release.

Low: Change is needed 2+ years out incorporated through annual release.

Requestor PEO STRI CC POC

Requirements Document List of applicable driving requirements document

Requestor PEO STRI CC POC

Point of Contact Name, telephone number, and email of the requestor.

Requestor PEO STRI CC POC

Requesting Entity Contractor, PM, Agency name Requestor PEO STRI CC POC Table 1

Change Request Data Items

Common Core Roadmap Data Items Data Item Description Reviewed

By Approved By

ID Unique numerical identifier for each change item

CCB CCB Chairperson

Status Identifies the state of the change.

Options include:

• Pending CCB Review

• Impact Assessment

• Pending Revision

• Pending Solution

Development

• Solution Development

• Baseline Integration & Test

• Integrated

• Rejected

• Cancelled

CCB CCB Chairperson

Title High Level Description of Change. CCB CCB Chairperson

Point of Contact Name, telephone number, and email of the requestor.

CCB N/A

Requesting Entity Contractor, PM, Agency name CCB N/A Category General nature of the change.

Categories include:

• Sustainability/Supportability

• Cybersecurity

• Future Cost Savings

• Future Program Support

• Usability Improvement

• New Feature

• Bug Fix / Correction

CCB CCB Chairperson

Change Description Brief description of the change. CCB CCB Chairperson Benefit/Rationale Brief description of the benefit of the change CCB CCB Chairperson

Scale/Impact High, Medium, Low rating for the impact to the current baseline representative of the amount of work to implement the change.

CCB CCB Chairperson

Need-By Date Date by which the change needs to be released for use.

CCB CCB Chairperson

Priority Rating of High, Medium, or Low representative of the urgency of the change.

High: Change is needed as soon as can be available.

Medium: Change is needed within 1-2 years incorporated through annual release.

Low: Change is needed 2+ years out incorporated through annual release.

CCB CCB Chairperson

Requirements Document List of applicable driving requirements document

CCB CCB Chairperson

Funding Source If applicable, this field will list the source(s) of funding for the requested change

CCB CCB Chairperson

Estimated Incorporation Period

Fiscal Year Quarter in which the change is estimated to be incorporated (i.e. 1QFY23)

CCB CCB Chairperson

Table 2 Common Core Roadmap Data Items

Configuration Control Board Members Member Bi-Weekly WG

Participation Voting

Member CCB Chairperson – PEO STRI FMT Product Line APM (Responsible for organizing, facilitating, and guiding the WG. Mediates CCB discussion and approves CC Roadmap data items)

X X*

PEO STRI (representation from each product team in the PL) X Platform PM Representatives (Stakeholders) Optional/As Needed X Requirements Owners (Stakeholders) X X Schoolhouse Representatives Optional/As Needed Common Core Contractor X Product Contractors X

*CCB Chairperson only votes in the event no other voting members are present and the change does not impact requirements or cost

Table 3 Configuration Control Board Members

Common Core Change Identified

Submit Change Request to

PEO STRI CC POC

Role: Requestor

Update Common Core Roadmap

Status: Pending CCB Review

Role: PEO STRI CC POC

START

Present Change Request at Bi-Weekly Working

Group / CCB

Role: Requestor

Conduct Impact Assessments

Role: PEO STRI Product Teams and Contractors

Present Impact Assessment at Bi-Weekly

Working Group / CCB

Role: PEO STRI Product Teams and/or Contractors

Have impacts been assessed? No

Yes

Change Approved to Proceed?

Yes

Revise or Reject Change

Request?

Reject

Revise

Revise Change Request

Role: Requestor

No

Update Common Core Roadmap

Status: Rejected

Role: PEO STRI CC POC

Yes

Closed

Develop Change Solution

Role: CC Contractor

Update Common Core Roadmap

Status: Pending Solution Development

Role: PEO STRI CC POC

Present Solution at Bi-Weekly Working

Group / CCB

Role: CC Contractor

Solution Approved?

No

Yes

Integrate Change into Common Core Baseline

Role: CC Contractor

Update Common Core Roadmap

Status: Integrated

Role: PEO STRI CC POC

Closed

Is the Change still desired?

Yes

No

Update Common Core Roadmap

Status: Baseline Integration & Test

Role: PEO STRI CC POC

Government Test of Change

Role: FMT PL Team

Did Update Pass Testing? Yes

No

Correct Deficiencies

Role: CC Contractor

Release CC Software Update

Role: CC Contractor (intermediate) or PL TSO (annual)

Is Change HW or SW?

SW

HW Update Approved for Release

Role: PEO STRI Product Teams

HW

Change Approved for Release? Yes

No

Discuss Path Forward at Bi-Weekly Working

Group / CCB

Role: CCB

Update Common Core Roadmap

Status: Impact Assessment

Role: PEO STRI CC POC

Update Common Core Roadmap

Status: Pending Revision

Role: PEO STRI CC POC

Discuss Test Results at Bi-Weekly Working

Group / CCB

Role: CC Contractor

Cost Impacts Approved and

Funding Available?

No

Coordinate with Platform PMs for Bi-Weekly

Working Group / CCB participation to brief Cost

Impacts

Technical Team Input

PM Input Technical Team Input

Logistics Input Cybersecurity Input

Legend

CCB Vote Required to Proceed

Input from non-CCB parties to support CCB process

Decision Point (Non-voting) Action

Beginning or End of Change Flow

Is change acceptable for CCB review?

Yes

PEO STRI Internal Review of Change Request

Role: PEO STRI CC Team

Is Change Approved by

Requirements Owners?

Yes

No Is the

Change still desired?

Discuss Change at Bi-Weekly Working

Group / CCB

Role: CCB

No

Yes

Work with Requestor to revise change request (if necessary)

Role: PEO STRI CC Team and Requestor

No

Is the Change still desired?

NoYes

Finalize CC Roadmap Data Fields for Change Request

Role: CCB / CCB Chairperson

Solution Development Time Now?

Yes

No

Update Common Core Roadmap

Status: Cancelled

Role: PEO STRI CC POC

Closed

Does the change impact requirements?

Yes

No

Does the change impact cost?

No

Yes

Update Common Core Roadmap

Status: Solution Development

Role: PEO STRI CC POC

Figure 1 Common Core CM Process Flow