A21.2_Solicitation_W900KK19R0080_Att_0001_CEVT_SOW_2019FEB01.pdf

Statement of Work U.S. Army Construction Equipment Virtual Trainers (CEVT)

1 February 2019

Prepared by U.S. Army Program Executive Office for Simulation, Training, and Instrumentation

(PEO STRI)

12350 Research Parkway Orlando, FL 32826-3276

Proponent Reviewed By: ___________________ Brian E. Watson

LTC, FA

PdM CE/MHE

Engineering

Prepared By: ____________________ Concurrence: ____________________ Kien Le Jeffrey Meister Lead Systems Engineer, CEVT Chief Engineer, PdM VTS Date: _________ Date: __________

Acquisition Logistics

Prepared By: ____________________ Concurrence: ____________________ Iris Lloyd Matthew Brothers Lead Acquisition Logistician, CEVT Product Support Manager, PM TRADE Date: _________ Date: __________

Program Management

Submitted By:______________________ Approved By:_______________________ David J. Meyers LTC Steven D. Gutierrez Assistant Program Manager, CEVT Product Manager, VTS Date:___________ Date:___________

DISTRIBUTION STATEMENT C – DISTRIBUTION AUTHORIZED TO U.S.

GOVERNMENT AGENCIES AND THEIR CONTRACTORS; FOR THE U.S. ARMY

CONSTRUCTION EQUIPMENT VIRTUAL TRAINERS (CEVT) CONTRACT.

OTHER REQUESTS FOR THIS DOCUMENT SHALL BE REFERRED TO PM TRADE

((407) 384-5201).

SOW-2018-031

W900KK-18-R-0036

1. SCOPE……………………………

1.1 BACKGROUND

2. APPLICABLE DOCUMENTS

2.1 DEPARTMENT OF DEFENSE STANDARDS AND HANDBOOKS

2.2 AVAILABILITY OF DEPARTMENT OF DEFENSE STANDARDS

2.3 OTHER GOVERNMENT DOCUMENTS, DRAWINGS AND PUBLICATIONS

2.4 AVAILABILITY OF OTHER GOVERNMENT DOCUMENTS AND

PUBLICATIONS

2.5 NON-GOVERNMENT DOCUMENTS AND PUBLICATIONS

3. REQUIREMENTS

3.1 PROGRAM MANAGEMENT

3.1.1 INTEGRATED MASTER SCHEDULE (IMS)

3.1.2 MEETINGS AND REVIEWS

3.1.2.1 START OF WORK AND POST AWARD MEETING

3.1.2.1.1 POST AWARD MEETING ENTRY CRITERIA

3.1.2.1.2 POST AWARD MEETING EXIT CRITERIA

3.1.2.2 PROGRAM MANAGEMENT REVIEWS

3.1.2.3 INTEGRATED PRODUCT TEAM (IPT) MEETINGS

3.1.2.4 DESIGN REVIEWS

3.1.3 CONFIGURATION MANAGEMENT (CM)

3.1.3.1 CONFIGURATION CONTROL BOARD

3.1.3.2 CONFIGURATION MANAGEMENT PLANNING AND MANAGEMENT

3.1.3.3 CONFIGURATION IDENTIFICATION

3.1.3.4 CONFIGURATION CHANGE MANAGEMENT

3.1.3.5 CONFIGURATION STATUS ACCOUNTING

3.1.3.6 CONFIGURATION ITEM DATABASE

3.1.3.7 CONFIGURATION VERIFICATION AND AUDIT

3.1.3.7.1 PHYSICAL CONFIGURATION AUDIT (PCA)

3.1.3.8 SOFTWARE CONFIGURATION MANAGEMENT

3.1.3.8.1 SOFTWARE CONFIGURATION CONTROL BOARD

3.1.3.8.2 SOFTWARE ITEM DATABASE

3.1.3.8.3 SOFTWARE CONFIGURATION MANAGEMENT DATABASE

3.1.3.9 SYSTEM ENGINEERING INTERFACE

3.1.3.10 ENGINEERING CHANGE PROPOSALS (ECP) AND CONTRACT CHANGE

PROPOSALS (CCP)

3.1.3.10.1 ENGINEERING AND CONTRACT CHANGE PROPOSAL REVIEWS

3.1.3.10.2 DEVIATIONS AND WAIVERS

3.1.4 RISK MANAGEMENT (RM)

3.2 SYSTEMS ENGINEERING

3.2.1 SYSTEM DESIGN

3.2.1.1 SYSTEM DEFINITION STAGE

3.2.1.1.1 SYSTEM REQUIREMENTS REVIEW (SRR)

3.2.1.1.1.1 SRR ENTRY CRITERIA

3.2.1.1.1.2 SRR COMPLETION/EXIT CRITERIA

3.2.1.1.1.3 SRR PRODUCTS

3.2.1.2 PRELIMINARY DESIGN STAGE

3.2.1.2.1 PRELIMINARY DESIGN REVIEW (PDR)

3.2.1.2.1.1 PDR ENTRY CRITERIA

3.2.1.2.1.2 PDR COMPLETION/EXIT CRITERIA

3.2.1.2.1.3 PDR PRODUCTS

3.2.1.3 DETAILED DESIGN STAGE

3.2.1.3.1 CRITICAL DESIGN REVIEW (CDR)

3.2.1.3.1.1 CDR ENTRY CRITERIA

3.2.1.3.1.2 CDR COMPLETION/EXIT CRITERIA

3.2.1.3.1.3 CDR PRODUCTS

3.2.1.4 INTERACTIVE COURSEWARE

3.2.1.5 FABRICATION, ASSEMBLY, INTEGRATION AND TEST STAGE

3.2.1.6 PREPLANNED PRODUCT IMPROVEMENTS (P3I)

3.2.2 SOFTWARE ENGINEERING

3.2.2.1 SOFTWARE REQUIREMENTS DEVELOPMENT

3.2.2.2 SOFTWARE DESIGN AND IMPLEMENTATION

3.2.2.3 DISASTER RECOVERY MEDIA

3.2.2.4 PROGRAMMING LANGUAGE

3.2.3 HARDWARE AND SOFTWARE INTEGRATION

3.2.4 CYBERSECURITY

3.2.5 SPECIALTY ENGINEERING

3.2.5.1 TESTABILITY ENGINEERING

3.2.5.2 SAFETY ENGINEERING

3.2.5.2.1 HEALTH HAZARD ASSESSMENT

3.2.5.3 QUALITY ENGINEERING

3.2.5.3.1 TEST DISCREPANCIES

3.2.5.3.2 DISCREPANCY PROCESSING

3.2.5.3.3 TEST DISCREPANCY PRIORITIES

3.2.5.4 HUMAN FACTORS ENGINEERING

3.2.5.5 ELECTROMAGNETIC ENVIRONMENTAL EFFECTS (E3)

3.2.5.6 CONTAMINATE AND CORROSION CONTROL

3.2.5.7 STANDARDIZATION

3.2.6 PRODUCT DEFINITION DATA (PDD)

3.3 INTEGRATED LOGISTICS SUPPORT (ILS) PROGRAM

3.3.1 LOGISTICS MANAGEMENT

3.3.2 SUPPORTABILITY ENGINEERING

3.3.2.1 SUPPORTABILITY ANALYSIS AND LOGISTICS MANAGEMENT

INFORMATION

3.3.3 MAINTENANCE CONCEPT

3.3.3.1 INITIAL SPARES AND REPAIR PARTS

3.3.3.2 SPARES SELECTION REVIEW

3.3.4 FACILITIES

3.3.4.1 SITE ACTIVATION

3.3.4.2 SITE SURVEY

3.3.4.3 TRAINING SYSTEM INSTALLATIONS

3.3.4.3.1 DISPOSAL

3.3.4.3.2 FACILITY REPAIRS

3.3.4.4 ACCESS TO GOVERNMENT FACILITIES

3.3.5 TECHNICAL PUBLICATIONS

3.3.5.1 OPERATOR USER MANUAL

3.3.5.2 MAINTENANCE MANUAL

3.3.5.3 COMMERCIAL OFF-THE-SHELF (COTS) MANUALS AND ASSOCIATED

LISTS……

3.3.5.4 TECHNICAL PUBLICATIONS IN PROCESS REVIEWS (IPR)

3.3.5.5 TECHNICAL PUBLICATIONS VALIDATION

3.3.5.6 TECHNICAL PUBLICATIONS VERIFICATION CERTIFICATION

3.3.6 TRAINING COURSES AND PRODUCTS

3.3.6.1 INSTRUCTOR /OPERATOR TRAINING

3.3.6.2 SYSTEM MAINTENANCE TRAINING

3.3.7 ITEM UNIQUE IDENTIFICATION (IUID)

3.3.8 PACKING, HANDLING, STORAGE, AND TRANSPORTATION (PHS&T)

3.4 INTEGRATED TESTING

3.4.1 TEST MEASUREMENT AND DIAGNOSTIC EQUIPMENT

3.4.2 TEST READINESS REVIEW

3.4.2.1 TRR ENTRY CRITERIA

3.4.2.2 TRR EXIT CRITERIA

3.4.2.3 TRR PRODUCTS

3.4.3 CONTRACTOR VERIFICATION TEST (CVT)

3.4.4 IN PLANT ACCEPTANCE TEST (IPAT)

3.4.5 ON SITE ACCEPTANCE TEST (OSAT)

3.5 SYSTEM TECHNICAL SUPPORT

3.6 OPERATIONAL SECURITY

3.6.1 GENERAL PROTECTION AND CREDENTIALING

3.6.1.1 ACCESS AND GENERAL PROTECTION

3.6.1.2 CREDENTIALING

3.6.1.3 NON-CREDENTIALING

3.6.2 SECURITY

3.6.3 OPSEC TRAINING

3.6.4 ANTITERRORISM (AT) LEVEL 1 TRAINING

3.6.5 IWATCH TRAINING

3.6.6 ARMY TRAINING CERTIFICATION TRACKING SYSTEM (ATCTS)

3.7 INTERIM CONTRACTOR SUPPORT (ICS)

3.7.1 USAGE AND AVAILABILITY

3.7.2 SPARES REPLENISHMENT

3.7.3 TRANSITION PLANNING

1. SCOPE

This Statement of Work (SOW) describes the work to be accomplished by the contractor in providing the Construction Equipment Virtual Trainers (CEVT) and configured systems that comply with the CEVT System Requirements Document (SRD) PRF-PT-706. This SOW defines the effort to design, develop, integrate, manage, deliver, install, test, document and support CEVT In Accordance With (IAW) Army training requirements and ensure compliance with safety regulations. A Technical Data Package (TDP) shall be provided to the Government to operate, support and maintain CEVT.

1.1 Background

Headquarters Department of the Army (HQDA) directed the United States Army Engineer School (USAES) to consolidate three construction equipment Military Operation Specialties (MOS) into one MOS, 12N-heavy equipment operator. This consolidation is stressing the training resources at USAES which must train over 6,000 advanced individual training (AIT) multi-service students, including Soldiers, Airmen, Sailors, and Marines, as part of the Inter-service Training Review Organization (ITRO) course each year on the critical tasks of operating construction equipment. USAES begins 50 new classes per year at Fort Leonard Wood (FLW).

Additionally, the U.S. Army Reserve (USAR) and Army National Guard (ARNG) also train and reclassify 600 Soldiers each year to this MOS at various locations in the United States. The One Army Training Strategy requires that Active, Guard, and Reserve use the same methods of training to eliminate variations in the quality of training across the force. According to a Training and Doctrine Command (TRADOC) Analysis Center-White Sands Missile Range (TRAC-WSMR) Training Effectiveness Analysis (TEA) completed in 2009 on the Construction Equipment Operator Course, with the proper implementation, the use of immersive simulators can increase the effectiveness of the current training while reducing required resources. Program Executive Office for Simulation, Training, and Instrumentation (PEO STRI), at the request of Product Manager for Combat Engineer/Material Handling Equipment (PdM CE/MHE) and the USAES, is to provide CEVT to both train Soldiers upon initial entry and transition as well as provide the CEVT for sustainment training in the field. CEVT will assist in the transition from classroom to actual equipment by providing a null risk training environment. CEVT shall provide realistic and challenging training using simulated terrain and movement characteristics that enable the student to transfer motor skills from simulator to construction equipment. CEVT allows Soldiers to perform construction tasks that vary from leveling earth to excavating a trench and from constructing a stockpile to loading a haul unit.

2. APPLICABLE DOCUMENTS

The following documents are applicable to this SOW to the extent specified herein. In the event of a conflict between documents referenced herein and the contents of this SOW, the contents of the SOW shall be the governing requirement.

2.1 Department of Defense Standards and Handbooks

MIL-STD-130N Identification Marking of U.S. Military Property dated 17 December

MIL-STD-40051-2C Preparation of Digital Technical Information for Page-Based

Technical Manuals dated 15 Dec 2015 MIL-STD-46855A Human Engineering Requirements for Military Systems, Equipment, and Facilities dated 24 May 2011 MIL-STD-31000 Technical Data Packages dated 5 November 2009

MIL-HDBK-217F,

Notice 1&2

Reliability Prediction of Electronic Equipment dated 10 July 1992 and 28 February 1995.

MIL-HDBK-472,

Notice 1

Maintainability Prediction dated 12 January 1984

MIL-PRF-29612B Training Data Products dated 20 June 2011

2.2 Availability of Department of Defense Standards

Copies are available on the internet at URL: http://assist.daps.dla.mil/quicksearch/.

2.3 Other Government Documents, Drawings and Publications

TRADOC REGULATION 350-70 Army Learning Policy and Systems dated 6

December 2011

PRF-PT-706 CEVT System Requirements Document

TM 5-3805-293-10 Technical Manual, Operator’s Manual for Motorized Grader Model 120M dated December 2010

TM 5-2410-241-10 Technical Manual, Operator’s Manual for D7R Series II Dozer Type I with Winch, Type II with Ripper dated 31 October 2011

TM 5-3805-298-10 Technical Manual, Operator’s Manual for 924H Wheel Loader dated 30 January 2012

TM 5-3805-296-10 Technical Manual, Operator’s Manual for Military 621G Scraper dated March 2012

TM 5-3805-294-10 Technical Manual, Operator’s Manual for Hydraulic Excavator (HYEX)

USAES POI 713-12N10 (NS) Phases 3 & 4

CRM Lesson Plan Report Hydraulic

Excavator Operations (CRM) 052-12N10C02 / 2.0, Wheel Loader Operations (CRM)

052-12N10C03 / 2.0, Operate A Crawler Tractor (CRM)

052-12N10C04 / 2.0, Wheel Tractor-Scraper Operations (CRM)

052-12N10C05 / 2.0, Motorized Grader Operations (CRM)

052-12N10D01 / 2.0

Program of Instruction for the Construction Equipment Operators Course, Active Army, Army Reserve and National Guard Approved 21 Aug 2018

29CFR1910.1200 Occupational Safety and Health Standards Toxic and Hazardous Substances

MIL-PRF 32216A

Performance Specification Evaluation of Commercial Off-The-Shelf (COTS) Manuals and Preparation of Supplemental Data dated 12 August 2011

2.4 Availability of Other Government Documents and Publications

Copies of the above documents are available at PEO STRI, ATTN:SFAE-STRI-TRADE-VTS, 12350 Research Parkway, Orlando, FL 32826-3276.

2.5 Non-Government Documents and Publications

GEIA-STD-0007-B Logistics Product Data GEIA-HB-0007 Logistics Product Data Handbook IEEE 12207:2017 System and Software Engineering

3. REQUIREMENTS

3.1 Program Management

The contractor shall provide the overall management and administrative effort necessary to ensure that the requirements of this contract are accomplished. The contractor shall develop metrics to monitor process, configuration management activities and other significant activities that will impact program schedule, costs, performance and risk.

(DI-MGMT-80227) Contractor’s Progress, Status and Management Report

3.1.1 Integrated Master Schedule (IMS)

The contractor shall develop, implement, manage to, update and maintain the contract IMS. All contract schedule information delivered or presented at program reviews shall originate from the IMS and shall contain all critical events and exit criteria, accomplishments, predecessors and successors events and their dependencies. The IMS shall address total program activities including activities performed by major subcontractors. The contractor shall develop the logic resource loaded network that accurately portrays the sequence and relationship of activities defining the total development and production program. The activities and event times shall be updated to reflect accomplished activities and any changes. The contractor shall conduct critical path analysis of the tasks and identify problem areas and corrective actions required to eliminate or reduce schedule impacts.

(DI-MGMT-81861) Integrated Program Management Report (IPMR) Integrated Master Schedule

3.1.2 Meetings and Reviews

The contractor shall conduct, attend and participate in meetings and reviews to be held at both contractor and Government facilities including equipment fielding locations. The contractor shall establish the capability to communicate with PEO STRI, Orlando, FL; the U.S. Army Maneuver Support Center of Excellence (MSCoE), Ft. Leonard Wood, MO; and Program Manager Combat Engineer / Material Handling Equipment (PM CE/MHE), Warren, MI via teleconferencing with data sharing. Meetings and reviews will be co-chaired by a Government and contractor representative. The contractor shall be prepared to explain the reasoning, assumption and methodologies in arriving at particular conclusions, recommendations, or alternatives in the accomplishment of the tasks required by the contract. The contractor shall prepare drawings and other data, as required, to aid in the presentations. All drawings and other data presented during the meetings shall be included in the meeting minutes. The contractor shall have key personnel and support available to carry out the conference. The contractor shall make available facilities for Government only discussions during all meetings and reviews at the contractor’s facility. Subcontractors shall attend meetings and reviews when required to address key elements. The contractor shall prepare the agenda, record a list of all attendees (whether attending in person or via teleconferencing), and record meeting minutes for all meetings and reviews. Meetings and reviews shall be considered fulfilled when all of the following items are completed:

a. A formal meeting has been conducted.

b. All topics required for discussion and presentation have been covered.

c. All action items requiring contractor response have been addressed.

d. The Government has accepted the meeting minutes.

The provisions of this paragraph shall apply to the following meetings and reviews. The listed meetings and reviews shall be conducted IAW with the appropriate subparagraphs below.

a. Start of Work and Post Award Meeting

b. Program Management Reviews

c. Integrated Product Team Meetings

d. Engineering and Contract Change Proposal Reviews

e. System Requirements Review

f. Preliminary Design Review

g. Critical Design Review

h. Test Readiness Reviews

(DI-ADMN-81505) Report, Record of Meeting/Minutes (DI-ADMN-81373) Presentation Material

3.1.2.1 Start of Work and Post Award Meeting

A Start of Work and Post Award meeting shall be held within a week after contract award at a mutually agreed to location. The Start of Work meeting shall be limited to the contractor’s key team members, with emphasis on top level management of the program, agreement on metrics to be used as management indicators during the program and partnering approach to implement.

The Post Award meeting shall establish the framework for the contractor and Government interaction during the performance period of the contract. At the Post Award meeting, the contractor shall present an Integrated Master Schedule (IMS) showing all critical milestones and supporting events, including logistics, leading to these milestones. The Post Award meeting shall include the presentation and discussion of information and data relating to:

a. Introduction and contract overview.

b. Discussion and clarification of CEVT SRD and SOW requirements.

c. Presentation of a complete, accurate and realistic IMS.

d. Identification of all critical paths within the IMS and detailed schedule.

e. IPT structure, membership and charters (roles and responsibilities).

f. Action item reporting and status.

g. Updated team contact list (names, IPT memberships, phone numbers and email address).

h. Metrics collection process, analysis and reporting.

3.1.2.1.1 Post Award Meeting Entry Criteria

Entry criteria for the Post Award meeting shall consist of:

a. Contract award has occurred

b. Government concurrence that the contractor-submitted Post Award meeting agenda is complete and acceptable.

c. IMS

3.1.2.1.2 Post Award Meeting Exit Criteria

Exit criteria for the Post Award meeting shall consist of:

a. Government concurrence that all required Post Award meeting topics have been satisfactorily presented, discussed and documented.

b. Government understands the IMS and detailed schedule are complete, accurate and realistic.

c. Government concurrence that the IPT structure, membership and charters are satisfactorily defined, documented and implemented.

d. Submittal and acceptance of the Post Award meeting minutes, including presentation materials.

f. All action items have been assigned with suspense date for closure.

3.1.2.2 Program Management Reviews

The contractor shall conduct formal program management reviews on an average of one every three months in accordance with the IMS. The location of the reviews shall be mutually agreed upon. The program management review shall provide a program overview and a detailed discussion of pre-selected topics. Status and information at the review shall reflect currency since the previous review.

3.1.2.3 Integrated Product Team (IPT) Meetings

The contractor shall establish an IPT structure to address major areas of system development (e.g., systems engineering, hardware design, software design, integrated logistics support testing). The contractor shall establish IPT charters and host regularly scheduled IPT meetings or teleconferences. The specific locations, dates and duration of the meetings shall be as specified in the IMS. The contractor shall prepare the meeting agendas and document the meeting results. The IPT meetings/teleconferences shall be used to address systems development status of activities, questions and issues in a timely manner between management reviews. The contractor shall document action items and due dates, coordinate resolution and track action items until closure. Action item closure shall require contractor and Government approval. Except where noted herein, meetings shall be considered fulfilled when all of the following items are completed:

a. A formal review meeting has been conducted.

b. All action items requiring contractor response have been documented and posted.

c. Submittal of meeting minutes.

3.1.2.4 Design Reviews

The contractor shall conduct design reviews for the purpose of assessing technical progress. The contractor shall document the results of each review, including agenda, attendees, material presented, discussions and any resulting action items in the meeting minutes. A design review shall be conducted at the completion of each application of the system-engineering phase. Each review shall accomplish the following:

a. Assess the system requirements and allocations to ensure that requirements are unambiguous, consistent, complete, feasible, verifiable and traceable to top-level system requirements.

b. Assess the design maturity based on technical development goals, IMS events and accomplishments, and empirical analysis and test data supporting progress to date.

c. Present the risks associated with a continued development effort.

d. Assess the life cycle processes and infrastructure necessary for product sustainment throughout the system life cycle.

e. Identify resources required for continued development.

f. Determine whether to proceed with the next application of the systems engineering process, to discontinue development, or to take corrective actions before proceeding with the development effort.

3.1.3 Configuration Management (CM)

The contractor shall establish and maintain a CM program to establish and maintain consistency between system requirements, system configuration information and all relevant information about the system. The consistency established through the CM process shall ensure that the system conforms to the requirements. The CM program shall ensure component interchangeability, accurate system information and safety of system operation and maintenance.

As the configuration information becomes more detailed and definitive throughout the development cycle, the contractor shall define configuration baselines. The contractor shall capture the performance, functional and physical attributes of each baseline. The contractor shall archive the defined attributes in the baseline in an integrated database. Both the system and its information shall be verified for consistency. The contractor shall identify and evaluate the impact of all proposed changes through the configuration change management process, including the verification that the system and all associated component information have been updated and continue to be consistent.

3.1.3.1 Configuration Control Board

The contractor shall participate in a Configuration Control Board (CCB) chaired by the Government. The CCB is responsible for managing changes to the CEVT baseline. The contractor shall document the hardware, software and firmware configuration and track changes to the CEVT system and components as a result of contractor/subcontractor recommendation or from Government request. The contractor shall submit proposed changes and associated costs for changes that may modify form, fit or function of components at the Line Replaceable Unit (LRU) level to the CCB. The change will be submitted in contractor’s Engineering Change Notice (ECN) format. The contractor shall give the Government 5 working days notice of a scheduled CCB. If the change is approved by the CCB, the contractor shall incorporate all changes in the CEVT documentation. The contractor shall not incorporate a change that modified form, fit or function at the LRU level without CCB approval. Refer to sections

3.1.3.10 for proposed changes.

3.1.3.2 Configuration Management Planning and Management

The contractor shall establish processes and tools to initiate and maintain consistency between system requirements, system configuration information and all relevant information about the system. The contractor shall:

a. Plan implementation of the CM functions for the context and environment in which they are to be performed and manage in accordance with the planning.

b. Determine the specific CM value-adding functions and levels of emphasis.

c. Document CM functions to provide the consistency between the system’s attributes, system definition information and the system’s configuration information, throughout the applicable phases of the life cycle.

d. Identify resources required to implement the CM functions and ensure they are applied throughout the system’s life cycle.

e. Assess the effectiveness of CM plan implementation and performance.

f. Flow down responsibility for CM to subcontractors.

g. Plan and identify information status levels for managing system configuration information and ensure that transmitted data products are usable.

3.1.3.3 Configuration Identification

The contractor shall provide unique identifiers for selected system attributes, system information and components to be used as the basis for configuration management. The contractor shall:

a. Define the functional, performance, interface and physical attributes of the system and components.

b. Determine the system’s composition using its product definition information.

c. Assign unique identifiers to configuration items so that:

i. one can be distinguished from other items.

ii. one configuration of the system can be distinguished from another.

iii. the source of a component can be determined.

iv. the correct system definition information can be retrieved.

d. Assign unique unit identifiers to individual components of the system.

e. Update component identifiers when a system is modified so that it reflects the new configuration without altering the system identifier and model identifier.

f. Uniquely identify information so that it can be correctly associated with the applicable configuration of the system.

g. Apply information identification rules to maintain representation and version relationships.

h. Maintain relationships between information, information requirements and the related system configuration to ensure accurate information retrieval.

i. Establish complete and valid descriptions of the attributes of the system and components at a point in time and provide a known configuration to which changes can be addressed.

j. Identify interfaces and establish mutually agreed-to control of common attributes for system or component boundaries that interface to the system or within the system.

3.1.3.4 Configuration Change Management

The contractor shall establish a systematic and measurable configuration change management process for managing product configuration changes and variances. Once the system requirements have been approved by an authorized management activity and the Government, the contractor shall update the baseline requirements to reflect the changes. The contractor shall:

a. Document and uniquely identify each change.

b. Classify requested changes to aid in determining the levels of review and approval.

c. Clearly and completely document request for change.

d. Consider the technical, support, schedule and cost impacts of a requested change before making a judgment as to whether the change should be approved for implementation and incorporation in the system and its documentation.

e. Determine potential effects of a change and coordinate impacts with the impacted areas of responsibility.

f. Determine the impacts for each change and identify which units of the system are to be changed, the point of production break-in and which units will be included in a retrofit.

g. Verify implementation of a change to ensure consistency between the system, its documentation and its support elements.

h. Document variances, when authorized by the appropriate level of authority.

3.1.3.5 Configuration Status Accounting

The contractor shall provide access to accurate, timely information about the system and its documentation through an integrated database. The contractor shall correlate, store, maintain, and provide readily available views and system configuration information including pending, current and historical data. The contractor shall:

a. Systematically record, safeguard, validate and disseminate system information.

b. Establish methods, processes and procedures to provide controlled access to system information.

c. Capture configuration information as it evolves.

3.1.3.6 Configuration Item Database

The contractor shall capture software and hardware design data in a CM controlled database and shall provide a shared data source for the exchange and reuse of technical information. The contractor shall develop Computer Software Configuration Item (CSCI) data to populate the software database. The contractor shall provide the capability to establish, modify, make available and maintain the integrity of the database. The contractor shall maintain the configuration item database until and through transition. This database shall be separate from the engineering development database.

The contractor shall capture hardware design data in a CM controlled database and shall provide a shared data source for the exchange and reuse of technical information. The contractor shall provide a copy of any tools (software) necessary to view the hardware technical information and identify any hardware requirements necessary to utilize the tool to the Government upon contract award at the Start of Work meeting. The contractor shall provide the capability to establish, modify, make available and maintain the integrity of the database. The contractor shall maintain the hardware item database until and through transition.

3.1.3.7 Configuration Verification and Audit

The contractor shall maintain surveillance over the CM process to ensure that requirement attributes are met and accurately documented. All verifications and audits conducted in accordance with the contractor’s CM/audit processes shall be documented and made available to the Government, including all non-deliverable documents. The contractor shall be responsible for identifying opportune timeframes for the Government to witness the contractor’s incremental configuration audits of the documentation, hardware components and software modules. The contractor shall be responsible for identifying recommended viewing times during the development process that allow components to be easily viewed prior to assembly to ensure that the TDP is successfully progressing towards completion. The Government will perform their verifications by reviewing a representative number of drawings, Government drawing filenames and associated technical manuals, software versions, logistics management information and manufacturing instructions. Government team corrective action findings shall be tracked by the contractor Quality Assurance (QA) representative to status discrepancies, redlines and corrective actions to closure. The Drawing Number Assignment Report (see section 3.2.6) shall include a Microsoft EXCEL spreadsheet listing all technical drawings with PEO STRI drawing numbers, matching Government filenames and identification of all revision levels and file dates for each technical drawing, COTS drawing and software version.

3.1.3.7.1 Physical Configuration Audit (PCA)

Prior to Test Readiness Review (TRR) a formal PCA will be conducted by the Government to demonstrate that the trainer satisfies PEO STRI Specification PRF-PT-706 requirements and that the deliverable hardware and software documentation accurately reflect the Configuration Items (CIs) and to establish the product baseline. The contractor shall record the results and deficiencies/corrections of the PCA in the Configuration Audit Summary Report. The contractor shall provide the personnel, equipment, and facilities necessary to support the PCA.

The contractor shall be responsible for removing and replacing the LRUs and access to the trainer equipment for conduct of the PCA, as required. At the completion of the PCA, any proposed configuration changes as a result of any contractor changes including in-plant or on-site testing activities shall be approved updated through Configuration Control Board prior to implementation. Any hardware identified for correction via the PCA shall be verified as corrected through at the TRR. The contractor shall individually review hardware changes with the Government on the trainer for any post TRR actions.

(DI-CMAN-81022D) Configuration Audit Summary Report and Certification

3.1.3.8 Software Configuration Management.

The contractor shall establish and document a software configuration management process. The contractor software configuration management plan may be incorporated into the software development process plans or may be a separate configuration management plan.

3.1.3.8.1 Software Configuration Control Board.

The contractor shall establish and maintain a software configuration control board or equivalent responsible for configuration control of its software configuration items and related software products. The software configuration control board will be responsible for COTS (including open source) management including product and version identification. The contractor shall ensure that all COTS products included in the system deliverable configuration are commercially supported.

3.1.3.8.2 Software Item Database.

The contractor shall capture software design data in a CM controlled database and shall provide a shared data source for the exchange and reuse of technical information. The contractor shall develop software item data to populate the software database. The contractor shall provide the capability to establish, modify, make available and maintain the integrity of the database. The contractor shall maintain the software item database until transition to the Government.

3.1.3.8.3 Software Configuration Management Database.

The contractor shall establish and maintain a software configuration management database in accordance with the software development process plan. The contractor shall establish a software database to store CSCI, Computer Software Unit (CSU) and Software Item (SI) data. A schema shall be developed for identification of software items and their versions. The database shall contain an audit trail whereby each modification, the reason for the modification, and authorization of the modification can be traced. The contractor shall perform the following:

a. Identification and recording of change requests.

b. Analysis and evaluation of the changes.

c. Approval or disapproval of the request.

d. Implementation, verification and release of the modified software item.

3.1.3.9 System Engineering Interface

A process shall allow simultaneous access to the common product data model with the ability to coordinate and update immediate changes to the product definition data. The configuration management system must handle all levels of product and process integration to build and support the product as well as manage the sequence of significant events. The information architecture must be able to capture changes to the system and notify affected team members.

3.1.3.10 Engineering Change Proposals (ECP) and Contract Change Proposals (CCP)

The contractor shall document and the IPT shall review all changes to established baselines and all changes to the requirements (other than the functional baseline). This includes changes to the Statement of Work, Contract Data Requirements List (CDRL), the contract schedule and the general provisions of the contract.

(DI-CMAN-80639D) Engineering Change Proposal (ECP)

3.1.3.10.1 Engineering and Contract Change Proposal Reviews

The contractor shall conduct a review with the Government of all proposed changes prior to the submittal of any engineering or contract change proposal in order to clarify requirements, format and content. Depending upon the criticality of the proposed changes, this review may take the form of a teleconference, a video-teleconference, a formal meeting at PEO STRI, or a formal meeting at the contractor’s facilities. All appropriate parties shall be in attendance in order to conduct a thorough, effective review. The contractor shall provide meeting minutes for all Engineering and Contract Change Proposal Reviews.

3.1.3.10.2 Deviations and Waivers

The contractor shall document the rationale and the potential impact of any deviation or waiver.

The contractor shall obtain approval before deviating from any Government controlled baseline.

(DI-SESS-80640D) Request for Variance (RFV)

3.1.4 Risk Management (RM)

The contractor shall prepare, implement and maintain a risk management process that includes identification, analysis, mitigation planning, mitigation plan implementation and tracking. The contractor risk management process shall measure future uncertainties in achieving program goals within defined cost, schedule and performance constraints. The contractor shall:

a. Identify and document moderate and high-risk items for each risk assessment area.

b. Identify and implement risk handling approaches and track over time each moderate and high-risk item.

c. Document risk issues that have been successfully resolved and schedule each open item into the program IMS.

d. Develop mitigation plans to identify the recommended critical path for contract completion and the appropriate risk handling approach to lower the level of uncertainty identified.

3.2 Systems Engineering

The contractor shall implement a system engineering process that transforms all system requirements into a set of lower level performance requirements that define the system. Systems engineering shall integrate all elements of a multifunctional engineering effort to meet system requirements. The contractor shall ensure the timely integration of engineering specialties such as reliability, maintainability, security engineering, logistics engineering, human factors engineering, safety, value engineering, standardization and transportability into design and development. The contractor shall develop and complete all planned IMS tasks for each milestone.

3.2.1 System Design

The contractor shall design, develop, produce and deliver the training devices in accordance with the CEVT SRD PRF-PT-706. The contractor shall use PRF-PT-706 as the basis for development of all lower level specifications.

3.2.1.1 System Definition Stage

The contractor shall establish the definition of the system with a focus on system products required to satisfy operational capabilities defined in the CEVT SRD PRF-PT-706. A System Requirements Review (SRR) shall be conducted at the completion of the systems definition stage for the purpose of determining whether the system definition is sufficiently mature to progress to subsystem definition. The system definition shall be reviewed to ensure that:

a. The design is sufficiently mature to meet systems requirements.

b. System-level risks have been addressed.

The contractor shall define, document, manage, and apply a requirements definition process in accordance with IEEE Standard 12207-2017 for all requirements and derived requirements from PRF-PT-706. A Requirements Traceability Verification Matrix (RTVM) shall be created or updated as required as part of the Requirements Definition phase. The RTVM shall capture requirements from traceability, analysis, validation, functional analysis, functional verification, synthesis and includes the capture of all elements resulting from test and evaluation efforts. The RTVM shall include the verification criteria for each requirement for testing purposes. The RTVM shall provide backwards and forward traceability, (i.e., the RTVM shall document each requirement from its source through definition, analysis, design, testing, and acceptance). The Contractor shall institute a configuration review process with the government for requirements review, approval, and control process by which RTVM data entry decisions are made.

(DI-MGMT-82133) Requirements Traceability Verification Matrix (RTVM)

3.2.1.1.1 System Requirements Review (SRR)

The System Requirements Review (SRR) is a multi-disciplined product and process assessment to ensure that the system under review can proceed into the development phase and that all system and performance requirements derived from the training requirements are defined/testable and consistent with cost, schedule, risk, technology readiness and other system constraints. This review assesses the system performance requirements and ensures that they are consistent with the system solution. Of critical importance to this review is the understanding of program technical risk inherent in the system performance specification. Acceptable level of risk is key to a successful review. The contractor shall conduct SRR IAW the IMS. The purpose of this review is to ensure all CEVT system requirements have been completely and properly identified and there is mutual understanding between the Government and contractor. This meeting shall include the presentation and discussion of information and data relating to:

a. Action item reporting and status.

b. Discussion and clarification of SRD and SOW requirements.

c. System test requirements and strategy.

d. Identification of all critical paths within the IMS and detailed schedule.

e. CDRL delivery schedule and status.

f. Training package approach.

g. Technical publications approach.

h. Systems Engineering overview.

i. Program specific CM plan (to include data management).

j. Program specific Quality Assurance and Management Plan (QAMP) (to include Software Quality Assurance).

k. Program specific Risk Management Plan (RMP).

l. Metrics collection process, analysis and reporting.

m. Human System/ergonomics considerations.

n. Requirements traceability matrix and verification methods.

o. DoD Item Unique Identification (IUID) requirements.

p. Logistics support status to include Life Cycle Support and Maintenance requirement.

q. Long lead time item identification and status.

r. Hardware production status.

s. Suitability of any proposed GFI/GFE/COTS/GOTS integrated solution with all issues identified, including other Non-Developmental Items.

3.2.1.1.1.1 SRR Entry Criteria

Entry criteria for each SRR shall be due to the Government 15 days prior to the SRR and shall consist of:

a. Government concurrence that the Post Award meeting exit criteria has been met.

b. Government concurrence that the contractor submitted SRR agenda is complete and acceptable.

c. Government concurrence that the contractor has documented and implemented preliminary analysis of the program specific Systems Engineering, CM plan, RMP, QAMP and logistics.

d. Delivery and acceptance (as applicable) of all CDRL items scheduled to be delivered prior to SRR.

e. All of the following presentation materials have been submitted to the Government in advance of this meeting:

1. System performance specification.

2. System software functionality description.

3. Updated risk assessment.

4. Updated schedule data.

5. Updated logistics documentation.

6. Updated HSI related documentation.

f. Government preliminary review indicates that the presentation material is sufficient to support the SRR.

3.2.1.1.1.2 SRR Completion/Exit Criteria

The SRR is considered complete when:

a. Government concurrence that all required SRR topics have been satisfactorily presented, discussed and documented.

b. The system requirements as presented can satisfy the CEVT PRT-PT-706.

c. The system requirements are sufficiently detailed and understood to enable system functional definition and functional decomposition, test and evaluation.

d. The requirements can be met with the proposed technology.

e. Adequate processes and metrics are in place for the program to meet the requirements.

f. HSI and sustainment requirements have been reviewed and included in the overall system design.

g. The program risks are known and manageable for development. All system elements and technologies are sufficiently matured to enable low risk entry into engineering and manufacturing development.

h. The program is properly staffed.

i. Hazards have been reviewed and mitigating courses of action have been allocated within the overall system design.

j. Government concurrence that the IMS and detailed schedule are complete, accurate and realistic.

k. The minutes and presentation materials have been submitted to the Government within 5 days after SRR.

l. All action items have been assigned with suspense date for closure.

m. Initial draft of RTVM complete.

3.2.1.1.1.3 SRR Products

Completion of the SRR should provide the following:

a. An approved system performance design to meet the requirements.

b. A preliminary update of system requirements to hardware, software and human subsystems.

c. A preliminary update to all software components.

d. A comprehensive risk assessment.

e. A preliminary identification of logistics design and sustainment concept.

f. A technical report, with the following attachments:

1. List of attendees to include name, functional area represented, phone number and email address.

2. Meeting minutes.

3. Action items.

g. Updated Risk Assessment, including risks and mitigation options.

h. Initial draft of RTVM.

3.2.1.2 Preliminary Design Stage

The contractor shall initiate subsystem design and create subsystem-level definition and design-to baselines. Subsystem reviews shall be completed for each subsystem at the completion of its preliminary design stage. From the preliminary design stage, the below areas shall be discussed at the Preliminary Design Review:

a. The subsystem definition is sufficiently mature to meet the requirements.

b. Component allocations and preliminary component specifications are reasonable and provide a sound subsystem concept.

c. Subsystem risks have been assessed and mitigated.

d. Human system interfaces are identified and described in the subsystem design and are traceable to design requirements.

3.2.1.2.1 Preliminary Design Review (PDR)

The Preliminary Design Review (PDR) is a multi-disciplined product and process assessment to ensure that the system can meet the stated performance requirements within schedule (program schedule), risk and other system constraints. PDR determines whether the hardware, software, and human preliminary designs are complete and that the IPT is prepared to start detailed design and test procedure development. The contractor shall conduct a PDR for hardware and software during the phases identified in the IMS. The contractor shall present and describe the training system design, program status and schedule. The PDR shall also address the following:

a. System/Subsystem requirements.

b. System hardware and software design, including as applicable:

1. Requirements.

2. Computational system.

3. Visual system.

4. Networks and topology.

5. Data collection databases.

6. Software tools.

7. Hardware and software interfaces.

8. Design modularity and commonality.

9. Review of Preliminary Product Drawing/Models and Associated Lists.

10. CDRL delivery schedule and status.

11. Review of Systems Engineering, CM and QA status.

c. Review of Technical Publications structure.

d. Logistics design aspects and concerns.

e. System safety program progress including preliminary identification of potential hazards.

f. System test and evaluation.

g. Review of the Requirements Traceability Verification Matrix (RTVM) in Microsoft Excel and Dynamic Object Oriented Requirements System (DOORS) formats.

h. Reliability and Maintainability (R&M) predictions.

i. Parts management program status and identification of long lead time items.

j. IUID marking of trainer equipment.

k. Facilities planning.

l. Update of suitability of any proposed GFI/GFE/COTS/GOTS integrated solution with all issues identified, including other Non-Developmental Items.

3.2.1.2.1.1 PDR Entry Criteria

Entry criteria for the PDR shall be due to the Government 15 working days prior to the PDR and shall consist of:

a. A PDR agenda.

b. Delivery of all the applicable CDRLs.

c. Submittal of the DOORS update.

d. Preliminary hardware and software design completion.

e. Submittal and acceptance of the PDR agenda.

f. Preliminary logistics data to include how the Level of Repair Analysis (LORA) will be perform and how Logistics Product Data (LPD) reviews will be conducted.

g. An SRR that has been successfully completed and all SRR action items have been responded to.

h. Software CM tools.

i. R&M requirements allocated to the design.

j. PDR technical information is available to the Government prior to the review and includes:

1. Refined system performance specification.

2. Updated Risk Assessment.

3. CM status.

4. Updated HSI related documentation.

3.2.1.2.1.2 PDR Completion/Exit Criteria

The PDR is considered complete when:

a. The Government concurs that all required PDR topics have been satisfactorily presented, discussed and documented.

b. The Government concurs that the IMS and detailed schedule are complete, accurate and realistic.

c. The DOORS update is accepted by the Government.

d. All PDR action items are listed.

e. The Government approves of preliminary hardware and software design.

f. The program risk and strategy to mitigate known risk is acceptable to the Government.

g. The preliminary design satisfies the system requirements.

h. Relevant supportability requirements for fielding and sustainment have been addressed.

i. Adequate processes and metrics are in place for the program to succeed.

j. HSI design factors have been reviewed and included, where needed, in the overall system design.

k. The program schedule can be executed.

l. The PDR presentation materials are made available.

m. The PDR minutes are submitted and accepted by the Government.

3.2.1.2.1.3 PDR Products

Completion of the PDR should provide the following:

a. A technical report, with the following attachments:

1. List of attendees to include: name, functional area represented, phone number and email address.

2. Action items.

3. Meeting minutes.

4. Recommendation as to the technical readiness of the program to enter the next phase of development.

b. An updated risk assessment.

c. An updated program schedule including system and software critical path drivers.

d. Updated Logistics Product Data (LPD)

3.2.1.3 Detailed Design Stage

The contractor shall complete subsystem design down to the lowest component level and create a component requirements and verification definition and build-to product baseline for each component. Final component definition shall include the following: identification of recommended parts and interfaces; resolution of component-level risks for each component, down to the lowest sub-component; the design for quality factors to include producibility, verifiability, usability, supportability, trainability and disposability. Component reviews shall be completed for each component at the completion of the detailed design stage. From the detail design stage, the below areas shall be discussed at the Critical Design Review:

a. Each detailed component definition is sufficiently mature to meet measure of effectiveness and measure of performance criteria.

b. Component specifications are reasonable and provide a sound component concept.

c. Component and related life cycle process risks have been assessed and mitigated to a level appropriate to support the fabrication, assembly, integration and test phases.

d. Trade study data are adequate to substantiate that detailed component requirements are achievable.

e. Software architecture is described using three views: software module view showing the

CSCI, Computer Software Component (CSC) and Software Unit (SU); software runtime view showing the states and threads; and…