W900KK23R0005_Attach_17_CBID_III_VACR_IMI_AEC_PWS.docx

W900KK-23-D-0TBD / W900KK23FSAMP

PWS-2023-XXX

W900KK-23-R-0005 / W900KK23FSAMP

PWS-2023-XXX

Performance Work Statement For Sample Task Order Task Order W900KK23FSAMP Visual Aircraft Recognition (VACR) Interactive Multimedia Instruction Development (IMI) and Automated Electronic Classroom (AEC) for Product Manager Air Defense Artillery (PdM ADA)

4 November 2022

PREPARED BY:

U.S. Army Program Executive Office for Simulation, Training, and Instrumentation (PEO STRI) 12350 Research Parkway Orlando, FL 32826-3276

Reviewed By: _________________ Concurrence By:_____________________

Approved By: __________________ Job Smithed Product Manager SM Date: _________

Changes

Change Number

Contents

1. SCOPE.

This Performance Work Statement (PWS) defines and provides the requirements of the tasks to be performed under this Sample Indefinite Delivery/Indefinite Quantity (ID/IQ) Task Order (TO) W900KK23FSAMP. The contractor shall work in accordance with (IAW) the PWS for Computer Based Instructional Development III (CBID III) base contract W900KK-23-D-0TBD and this specific Task Order W900KK23FSAMP. The contractor shall perform all requirements as described in this PWS to provide Product Manager Air Defense Artillery (PdM ADA) with 1 Automated Electronic Classroom (AEC) and 5.00 Hours of Interactive Multimedia Instruction (IMI) courseware. The AEC will consist of procuring, installing, and integrating 10 desktop computer student stations in a classroom setting. The courseware will consist of developing 5.0 hours Visual Aircraft Recognition (VACR) IMI for Air Defense Soldiers, based on TC 3-01.80, and to be installed on the AEC student stations.

The contractor shall, unless otherwise stated, provide all material to make the systems referenced functional and operational. The detailed requirements and expected outcomes are defined in the PWS Appendix B.

1.1 Goals and Objectives: PEO STRI’s goal is to acquire training solutions utilizing accepted Instructional System Design (ISD) standards, simulation services, and products.

1.2 Background: PEO STRI is tasked to procure and support a full range of training products, services, and simulations for the overall effort of the TO. This TO will focus developing and delivering 1 AEC and creating 5.00 hours of new IMI.

1.3 Method of Tasking: This PWS and Contract Data Requirement Lists (CDRLs) DD Form 1423 define specific requirements associated with this TO.

2. APPLICABLE DOCUMENTS.

The following documents listed form a part of this PWS to the extent specified herein. In the event of a conflict between documents referenced herein and the contents of this PWS, the contents of this PWS take first precedence. Nothing in this PWS, however, supersedes applicable laws and regulations, unless a specific exemption has been obtained.

2.1 Government Documents:

3. REQUIREMENTS.

3.1 General Requirements: The requirements defined herein form the basis for all work performed for PEO STRI as a part of the TO. This PWS defines the scope of this TO on the Sample ID/IQ contract.

3.1.1 System Safety Tasks: (Not applicable for this TO)

3.1.2 Program/Project Management: The contractor shall provide the overall management/administrative effort necessary to ensure that the requirements of this ID/IQ contract and TO are accomplished. The contractor shall establish and maintain a comprehensive program management system to support the day-to-day management of support functions for this TO, to include, but not limited to, staff management, deliverable management, schedule management, performance management, cost management, risk management, configuration/quality control management, and liaison with Government representatives. The contractor shall maintain procedures to respond to Request for Proposals (RFPs) and ID/IQ contract TO modifications. The contractor shall document and deliver program status reports as required by the CDRL.

3.1.2.1 Monthly Status Report: The contractor shall provide a written Monthly Status Report (MSR). The MSR shall document the progress of the project, issues/concerns, and risk management data including risk assessment and impact information. MSRs shall include a phone log and a listing of action items for the project.

(DI-MGMT-80368A) Status Report

3.1.2.2 Production or Delivery Problem Report: Whenever the contractor has identified a problem that may have potential impact on delivery, schedule, or cost they shall submit a Production or Delivery Problem Report. The report shall contain complete but concise explanations as to the nature of the problem and the current or potential impact on the TO. It shall describe any actions the contractor has taken to remedy the situation.

(DI-MGMT-81178) Report, Production or Delivery Problem

3.1.2.3 Technical Management and Work Plan: The contractor shall develop a technical management and work plan to be presented at the Kick off Meeting (KOM). The Technical and Management Work Plan describes the contractor's plan to implement the PWS tasking provided via the TO.

(DI-MGMT-81117) Technical and Management Work Plan

3.1.2.4 Project Planning Chart: The contractor shall create a Project Planning Chart, subtitled Integrated Master Schedule (IMS) to identify training events and the delivery of all products. The IMS shall identify all significant tasks, events, and activities required to effectively manage project progress, technical performance, and cost for each deliverable. The IMS shall address total program activities including activities performed by major subcontractors. 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-80507C) Project Planning Chart

3.1.3 Conferences, Reviews, and Milestones: The contractor shall conduct, attend, and participate in conferences and reviews. Specific conferences and reviews associated with this ID/IQ contract TO include, but are not limited to: KOM, Data-Gathering, Site Inspection, Pre-Fielding Readiness Review, Install (Ready For Training), Train-the-Trainer, IMI Reviews, and Integrated Project Team (IPT), In-Process Review (IPR) meetings.

3.1.3.1 Kick off Meeting: The contractor shall host the KOM meeting per the IMS, within 10 business days after TO award. Contractor personnel and Government representatives shall attend. The contractor shall present the proposed IMS. The contractor shall explain the design, reasoning, assumptions, and methodologies used to develop the AEC and new IMI. In addition, the team shall discuss Government Furnished Information (GFI), the IMS, and reviews. The Government and the contractor shall use the KOM to communicate the roles and responsibilities of team members and present the planned approach to all members.

3.1.3.2 Integrated Product Team Meetings: The contractor shall use integrated product and process development to manage programs and participate in joint Government/contractor IPT meetings. The contractor shall conduct telephonic biweekly reviews throughout the TO. The purpose of these reviews shall be to apprise the Government of program status. The contractor shall keep the Government informed of the analysis and development process to ensure the final courseware meets the Government requirements. The contractor shall maintain a record of discussions, agreements, and technical issues that arise from the IPT. The contractor shall provide a memorandum for record (MFR) to document any points of contention.

3.1.3.3 In Process Reviews: The contractor shall conduct IPRs quarterly. Each IPR shall provide attendees with information regarding the status and planned activities of the program. The contractor shall submit presentation materials to be used during the IPR no later than (NLT) 7 business days prior to the IPR.

(DI-ADMN-81373) Presentation Material

3.1.3.4 Meetings/Minutes: The contractor shall provide the agenda for the KOM and face-to-face reviews. The contractor shall prepare and deliver the agenda in contractor format three business days prior to the meeting. The contractor shall write minutes, review input from all team members and coordinate the minutes and action items with the attendees before adjourning the meeting. The contractor shall include any global decisions or incremental review comments in the minutes. Global comments and decisions include those that are not limited to the single course topic or lesson, but apply to multiple or all topics and lessons. The contractor shall maintain a list of decisions and comments, which shall be carried over to all subsequent minutes. The contractor shall prepare and deliver the minutes.

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

3.1.4 Design Reviews: The contractor shall conduct reviews, with Government participation, to include design reviews. The contractor shall document the results of the review, including any resulting action items. Each review shall accomplish the following:

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

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

0. Present the risks associated with a continued development effort

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

0. Identify resources required for continued development

0. 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

The contractor shall conduct system design reviews, with Government participation, for each level of development. Reviews may result in the need to iterate through the system engineering process to resolve identified deficiencies before progressing further into the development activity. The contractor shall ensure satisfactory completion of supporting documentation and completion of qualification tests for each specification requirement. The contractor shall ensure all requirements were satisfied and products comply with final drawings.

At design reviews, the contractor shall present the systems security design, initial security risk assessment, security test approach, security training approach, and any other security relevant information.

3.1.4.1 System Requirements Review (SRR): The contractor shall conduct the SRR as a product process assessment to ensure the system definition is complete. The purpose of the SRR is to ensure performance requirements, derived from overall requirements, is complete, properly identified, defined, testable, and consistent with schedule, risk, technology readiness, and other system constraints. The review shall include the presentation and discussion of information and data relating to the following:

1. System Requirements Document

1. System software functionality description

1. Preferred system solution definition

1. Hardware/software allocation

1. Human interfaces

1. Data collection

1. Test Plan

3.1.4.1.1 SSR Entrance Criteria: Entry criteria for the SRR shall consist of:

a. Government review of the SRR (preliminary) presentation material indicates it is sufficient to support the SRR

b. Documented results of the data collection and GFI/Government Furnished Equipment (GFE) tasks are complete

c. Draft Requirements Traceability Matrix (RTM) document submitted for review

3.1.4.1.2 SSR Exit Criteria: The SRR shall be complete when:

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

b. The system requirements, as disclosed, satisfy the requirements of the PWS

c. The system requirements detail and enable system functional definition, functional decomposition, test, and evaluation

d. The program risks are identified

e. The minutes and presentation materials have been submitted and agreed to

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

3.1.4.2 Preliminary Design Review (PDR): The contractor shall conduct a PDR to present the results of the Preliminary Design phase of the Systems Engineering effort. The PDR shall address the preliminary design criteria in 3.1.4.1. The contractor shall notify the Government no less than thirty (30) calendar days prior to the planned PDR in order to extend invitations to all program stakeholders. The contractor shall have PDR materials delivered to the Government at least five (5) business days prior to PDR event. The contractor shall document action items, due dates and coordinate resolution and track action items until closure. Action item closure shall require contractor and the Government’s approval.

3.1.4.2.1 Preliminary Design Review Entrance Criteria: Entrance criteria for the PDR shall consist of Government concurrence with the following items:

1. Completed SRR and all prior Action Items are closed

1. CDRL items scheduled to be delivered prior to PDR have been delivered and accepted (when applicable) IAW CDRL requirements

1. Risk assessments and risk mitigation plans have been developed

1. IMS shows critical path through CDR

1. Program technical risk is medium or lower

1. Program execution risk is medium or lower

1. PDR agenda has been submitted and accepted

1. PDR presentation materials are available at least 5 business days prior

1. Complete hardware architecture

1. Trade-off analysis (if any)

1. Approved Government inspection of all incremental development

1. Final report of the proposed GFI/GFE/COTS/GOTS integrated solution with all issues identified at PDR, including other Non-Developmental Items

3.1.4.2.2 Preliminary Design Review Exit Criteria: The contractor shall consider PDR complete when the Government signs off all action items with the understanding that there is an acceptable level of program risk and the Sample TO Assistant Project Manager (APM) signs and accepts the PDR Meeting/Minutes/CDRL.

3.1.4.3 Critical Design Review: The contractor shall conduct a CDR to present the results of the Detailed Design phase of the Systems Engineering effort. The contractor shall notify the Government no less than thirty (30) calendar days prior to the planned CDR in order to extend invitations to all program stakeholders. The contractor shall have CDR materials delivered to the Government at least five (5) business days prior to CDR event. The contractor shall document action items, due dates and coordinate resolution and track action items until closure. Action item closure shall require contractor and Government approval. The contractor shall address design changes made since the PDR.

After the Government has approved the design at CDR, the contractor shall submit ECPs (if any) to the Government for review and approval, prior to proceeding to implementing the proposed changes to the configuration management baseline.

3.1.4.3.1 Critical Design Review Entrance Criteria: Entry criteria for the CDR shall consist of Government concurrence with the following items:

a. PDR action items are closed

b. CDRL items scheduled to be delivered prior to CDR have been delivered and accepted (when applicable) IAW CDRL requirements

c. Product baseline has been updated and established

d. Updated risk assessment and risk mitigation plans are available

e. Risks and their respective mitigation plans are in place and manageable for implementation of the functional requirements into a final design

f. The design addresses Reliability and Maintainability (R&M) requirements

g. Trade-off analyses have been completed (if any)

h. Logistics analysis has been completed and plans have been established

i. IMS shows critical path through testing

j. CDR agenda has been submitted and accepted

k. Program schedule is executable within the anticipated cost and technical risks

l. Program is properly staffed

m. CDR presentation materials are delivered to the Government at least 5 business days prior

n. Detailed Hardware Listing to include manufacturer, type and model

o. Software Listing to include manufacturer and version

p. Ports, Protocols, and Services (PPS)

q. CS Scanning Tools and plans

r. Updates to draft Technical publications are complete

s. Approved Government inspection of all incremental development

t. Final report of the proposed GFI/GFE/COTS/GOTS integrated solution with all issues identified at PDR resolved, including other Non-Developmental Items

3.1.4.3.2 Critical Design Review Exit Criteria: The contractor shall consider CDR complete when the Government signs off all action items with the understanding that there is an acceptable level of program risk and the Assistant Project Manager (APM) signs and accepts the CDR Meeting/Minutes/CDRL.

3.1.5 Test Readiness Review: The contractor shall schedule a formal TRR with the Government no later than five (5) working days prior to any IPAT and OSAT event. The contractor shall address the following key issues at the system engineering TRR prior to the start of formal testing to ensure that the system and all the test resources are ready to begin testing:

a. Test procedures comply with plans and descriptions, are adequate to accomplish test requirements and satisfy requirements for verification

b. Pre-test predictions and informal tests indicate testing will confirm performance

c. New or modified test equipment and facilities and procedure manuals required to accomplish planned test and evaluation, are available and satisfy the test requirements

d. Data acquisition and reduction provisions are in place (if applicable)

e. Technical publications are completed and validated

f. System to be tested has completed an official Government CS scan

g. The contractor shall maintain Software Support Environment (SSE) hardware and software during this contract.

The contractor shall review during TRR the following documentation:

· Evidence that the test management system as required under the contract is ready to accept the qualification tests and their results

· Evidence that the requirements in the development specification have been traced to qualification tests or tests on which the qualification tests rely

· A list of outstanding discrepancy reports, both external and internal cross-referenced to the contracted deliverable end items or development hardware and software products

· Evidence of all internal process tests and inspections has been completed by the contractor and support transition into formal tests

· Test requirements

· Requirements changes pending

· Design changes since the last design review

· Test constraints based on previous testing or test hardware limitations

· Test configuration (test article and instrumentation and support equipment)

· Approved test plan and test procedures

· Plans for collection, reduction and analysis of the test data

· Calibration plan and status

· Problem areas and their resolution

· Validated technical publications

· CS Scan results

· Contractor’s in process test results

· Present test procedures inclusive of M&S, V&V tests

(DI-NDTI-80566A) Test Plan

3.1.5.1 TRR Entrance Criteria: The contractor shall provide:

a. Configuration of the AEC under test has been defined, updated and agreed to.

b. All applicable functional, unit level, subsystem, system, and qualification testing has been conducted successfully to include official Government CS scan.

c. All TRR specific materials such as Government approved test plans, cases, and procedures have been available to all participants prior to conducting the review (minimum of 7 working days).

d. All known system discrepancies identify and resolve in accordance with an agreed to plan.

e. All previous design review exit criteria and key issues have been satisfied in accordance with an agreed to plan.

f. All required test resources (people, facilities, test articles, test instrumentation) identify and are available to support required tests.

g. Define roles and responsibilities of all test participants and agreed to.

3.1.5.1 TRR Exit Criteria: The contractor shall provide:

a. Proper Government disciplines represented at the review. If applicable, were all of the required independent evaluators involved and do they concur with the planned tests and expected results.

b. Adequate test plans are completed and approved for the system under test.

c. Adequate identification and coordination of required test resources is completed.

d. Previous component, subsystem, system test results form a satisfactory basis for proceeding into planned tests.

e. Risk level identified and accepted by Program leadership.

f. CS Scan results and mitigation plan

3.1.6 Data Preparation and Management: The contractor shall develop, manage, and deliver acceptable contractually required data. This requirement includes all data deliverables cited in this ID/IQ TO and all source documents required to prepare the CDRL items.

The following requirements shall apply:

a. The contractor shall ensure that all data items to be delivered to PEO STRI meet the quantity and quality requirements of the ID/IQ contract TO CDRL.

b. The contractor shall establish data management procedures and policies to provide control and configuration management of all contractually required data. To ensure subcontractors meet the contract data requirements set forth in the ID/IQ contract TO CDRL, the prime contractor shall maintain control of all data developed by subcontractors for any ID/IQ contract TO.

c. The contractor shall establish and maintain data libraries consisting of technical manuals, parent system technical description, and software documentation, for that data developed for training systems devices and other data pertaining to training systems.

3.1.6.1 In-Plant Acceptance Test (IPAT):

Note: IPAT will be conducted without outputs. IPAT will verify hardware and IMI working compatibility. The contractor shall test the AEC in its final configuration, with Government’s participation, at in-plant acceptance testing, prior to shipment to the location in accordance with the approved test procedures. The contractor shall provide a test schedule covering the AEC testing event. The contractor shall notify the Government at least two weeks in advance prior to being ready for test. These tests shall verify the functionality and performance of the system and that the AEC complies with the approved specification requirements. The contractor shall document, correct, and re-test any discrepancies/problems found during testing.

3.1.6.2 Legacy System Test:

N/A

3.1.6.3 On-Site Acceptance Test (OSAT): The contractor shall support the Government site acceptance test for equipment to verify that the installed equpiment functions properly and operates to the specified performance requirements. The contractor shall conduct testing using Government approved sub-set of the In-Plant Acceptance Test procedures. Prior to Government acceptance, the contractor shall document, correct, and re-test any discrepancies/problems found during testing. The contractor shall document the results of the OSAT.

3.1.6.4 Modeling and Simulation Verification and Validation (M&S V&V) The purpose of the M&S V&V process is to provide objective evidence that the performance of the IMI, when in use, meets the requirements of this PWS and that the simulator accurately and completely represents the operational environment. The contractor shall define, document, manage, and apply an M&S V&V process IAW MIL-STD-3022 that evaluates the system’s modeling of ship performance.

3.2 Technical Capabilities: The contractor shall have the capability to analyze, design, develop, implement, evaluate, and sustain any service, product, device, or system required. The required capabilities are defined below:

a. Adopt and incorporate Commercial Item hardware and software for the installation of computer-based training delivery systems.

b. Ensure programs and processes are developed, documented, and implemented to provide quality systems and products.

c. Provide Information Technology (IT) services to support training and simulation products and systems.

d. Model, simulate, and network systems, synthetic environments and changes to the environments resulting from the simulation of IMI or Desk Top Trainer (DTT) services and products, in context to the requirements defined in this Statement of Work.

e. Adopt and incorporate Commercial Item (See FAR 2.101) hardware and software as well as new technologies for the simulation of platforms and environments.

f. Analyze; model and simulate; design; develop; produce; modify; test; deliver; refurbish hardware/software components, courseware, and software as it relates to the support of training services and products, and customer requirements.

g. Produce training products IAW appropriate service regulations, standards, and specifications.

3.3 Management Capabilities: The contractor shall define and manage a flexible, executable management approach that takes full advantage of acquisition streamlining and reform initiatives. The required characteristics of this management approach are defined below.

a. Use integrated product and process development to manage programs and participate on joint Government contractor IPTs.

b. Incorporate streamlined management processes to plan, staff, organize, direct, and control (including tracking) to improve program performance, cost, and schedule.

c. The contractor shall maintain an effective risk management plan/policy to ensure work performed under this contract complies with the performance requirements of the ID/IQ contract TO issued under this contract. The plan shall specify contractor procedures to identify and prevent, and assure non-reoccurrence of risk management issues.

d. Accommodate Government insight into contractor technical performance, cost and schedule; risk management; and program control, during product design, development, integration, testing, production, delivery, and support.

e. Provide program data as required by the CDRL.

f. Establish and maintain a process for managing Associate Contractor Agreements (ACA).

g. Use software development, system engineering management, program management, and other plans.

3.3.1 Quick Reaction Capability: (Not applicable for this TO)

3.3.2 Requirements Traceability: The contractor shall establish a means to track and account for requirements throughout the services and products evolution.

3.3.3 System Design: The contractor shall use this PWS as the basis for development of all implementing specifications. The design concept shall establish the engineering specifications and standards adopted by industry standards bodies or de facto standards (set by the market place). Performance, cost, industry acceptance, long term availability, supportability, and upgrade potential shall support in determining selected designs and specifications.

3.3.3.1 System Definition Phase: The contractor shall define, document, manage, and apply a requirements definition process IAW IEEE Std 12207-2008, section 6.4.1 for all requirements and derived requirements from this PWS. The Requirements Definition phase shall require the creation of or update to the Requirements Traceability Verification Matrix (RTVM). The RTVM shall be a direct input to the System/Subsystem Specification. 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 to support in the RTVM data entry decisions.

The contractor shall establish the definition of the system with a focus on system products required to satisfy performance requirements in this PWS. The contractor shall complete the system, product, and subsystem interface requirements and verification definition, system and product requirements and verification definition, and preliminary subsystem requirement and verification definition; establish a system baseline; and complete technical reviews. The requirements and initial design documentation generated during the system definition stage shall guide subsystem development. The contractor shall conduct the System Requirements Review (SRR), with Government’s participation, at the completion of the systems definition stage for determining whether the system definition is sufficiently mature to progress to preliminary design stage. The contractor shall review system definition to ensure that:

1. The design is sufficiently mature to meet systems engineering criteria

1. System functional requirements and system non-functional requirements (e.g., performance, design goals (e.g., Modular Open System Approach (MOSA)) are identified

1. System-level risks adequately address to justify continued development

1. Trade-study data are adequate to substantiate that system requirements are achievable

1. Interface requirements between human and products or subsystems identifies performance, workloads, design constraints, and usability

1. Selected CS products that are National Information Assurance Partnership (NIAP) validated or on the DOD Unified Capabilities (UC) Approved Products List (APL) (https://aplits.disa.mil/processAPList.do)

1. Decisions made in arriving at the system definition configuration support by analysis, test, and other technical data

3.3.3.2 Preliminary Design Phase: The contractor shall ensure that the design considerations include systems functional requirements, systems non-functional requirements (e.g., performance, design goals (e.g., MOSA, and Human System Interfaces)). The contractor shall ensure that functional design considerations integrate CS functional requirements and that these requirements are included throughout the development process. The contractor shall decompose identified subsystem functions into lower-level functions and allocate functional and performance requirements to component-level functional and physical architectures. Each preliminary subsystem requirements, verification definition, and preliminary design-to baseline shall evolve into a subsystem requirement, verification definition, and design-to baseline. Preliminary component requirements, verification definition, and build-to baselines shall define the components and the subsystem developed. Final subsystem definition shall include identification of recommended components and interfaces; resolution of subsystem-level risks; assessment of component risks; and design for quality factors to include producibility, verifiability, usability, CS, supportability, trainability, and disposability for each subsystem. The contractor shall complete subsystem reviews for each subsystem at the completion of its preliminary design stage. The contractor shall document the results of the evaluation. The purpose of each review is to assure that:

1. The subsystem definition is sufficiently mature to meet systems engineering criteria

1. The subsystem functional requirements and non-functional requirements (e.g., performance, design goals (e.g., MOSA)) are identified in the subsystem design and are traceable to the system functional and non-functional requirements

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

1. Software architecture is described using four views: 1) software module view; 2) software runtime view, 3) use case view, and 4) software deployment view

1. Subsystem risks have been assessed and mitigated to a level appropriate to continue development

1. Trade-study data are adequate to substantiate that subsystem requirements are achievable

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

1. Decisions made in arriving at the subsystem configuration definition are well supported by analysis and technical data

1. Security engineering processes are integrated into the design to achieve an integrated secure solution

1. Complete analysis of the proposed GFI/GFE/COTS/GOTS integrated solution conducted and any outstanding issues identified to the IPT for assessment.

The contractor shall present the AEC preliminary design to the Government at the Preliminary Design Review (PDR).

3.3.3.3 Detailed Design Phase: The contractor shall complete subsystem design down to the lowest component level, and create a component requirement, verification definition, and build-to component baseline for each component. Final component definition shall include identification of recommended parts and interfaces; resolution of component-level risks and for each component, down to the lowest sub-component, the design for quality factors to include producibility, verifiability, usability, CS, supportability, trainability, and disposability. The contractor shall complete component reviews at the completion of the detailed design stage for each component with Government participation. The contractor shall integrate security engineering processes into the design to achieve an integrated secure solution. The contractor shall document the results of the evaluation. The purpose of this review shall be to ensure that:

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

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

1. Component and related life cycle process risks assess and mitigate to a level appropriate to support the fabrication, assembly, integration and test phases

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

1. Software architecture describes using four views: 1) software module view; 2) software runtime view, 3) use case view, and 4) software deployment view

1. Human system interfaces are identified and describe in the detailed and are traceable to design requirements

1. The detailed software design (to include COTS/GOTS product name and version number) describes in terms of the satisfaction of functional and non-functional systems requirements

1. Decisions made in arriving at the detailed component definition configuration supports analysis and technical data

1. Security engineering processes integrates into the design to achieve an integrated secure solution

1. Government approves inspection of all incremental development

The contractor shall present the completed AEC design to the Government at the Critical Design Review (CDR).

3.3.3.4 Fabrication, Assembly, Integration and Test Phase: When inspection, analysis, demonstration, or tests determined product deficiencies exist, the contractor shall resolve any product deficiencies for the system, product, subsystem, assembly, or component. The contractor shall verify that the products designed satisfy specifications. The contractor shall integrate security engineering processes into the design to achieve an integrated secure solution. The contractor shall complete functional configuration audits, with Government participation, to verify that products have achieved requirements; that they satisfy the characteristics as specified in specifications, interface specifications, and other baseline documentation; and that test plans and procedures were complied. The contractor shall informally present results at the IPT meeting.

3.3.4 Software Engineering: (Not applicable for this TO)

3.3.4.1 Software Requirements and Architecture Development and Review: (Not applicable for this TO)

3.3.4.2 Software Design and Implementation: (Not applicable for this TO)

3.3.4.3 Software Development Test: (Not applicable for this TO)

3.3.4.4 Software Integrity Certification: (Not applicable for this TO)

3.3.5 Software Development: (Not applicable for this TO)

3.3.6 Training Services and Products Development: The contractor shall perform training and product services development tasks as required.

3.3.7 Hardware: Hardware requirements for Sample TO includes the use of Commercial Off-The Shelf (COTS) and Government Off-The Shelf (GOTS) systems for integration into existing training systems, modification of existing training systems, or development of DTTs/courseware in an IMI environment. The contractor shall generate and document hardware designs in accordance with the requirements.

(DI-ILSS-80872) Delivery of Training Materials

3.3.8 Manufacturing: (Not applicable for this TO)

3.3.9 Hardware and Software Integration: The contractor shall perform all activities to integrate and assemble the hardware and software to achieve a fully functional and accreditable system, with all support systems, that performs and operates IAW the system specification and contractor generated specifications. The contractor shall develop and document all external interfaces to other systems and all internal interfaces between hardware and software configuration items. The contractor shall provide interface descriptions for the entire design and for any of its modifications. The contractor shall include references to all applicable electrical and mechanical interfaces, commercial standards, message protocols, security issues, and precautions in descriptions. The contractor shall verify the complete integration of the hardware and software of each hardware and software subsystem and the overall system through the utilization of formalized test procedures. A system level production approval review shall be completed to demonstrate that the total system has been verified to satisfy specification and baseline requirements for each system level, and to confirm readiness for production, distribution, operations, support, training, continuing improvement, and disposal. The review shall ensure that:

a. Issues for the component, assemblies, subsystem, products and life cycle process and services are resolved

b. Test procedures for components, assemblies, and products were completed and were accurate

c. The system and products were confirmed ready for function and CS testing and accreditation

d. Test were conducted IAW established procedures

e. An audit trail from design reviews, held after detailed design, establish with changes substantiated, and all component, subsystem, and system products meet specification requirements

f. Risk-handling procedures are satisfactory for production

g. Evolutionary development requirements and plans have been refined

h. Planning is complete and procedures, resources, and other requisite people, products, and processes are available (or programmed to be available) to initiate production, distribution, operations, support, training, disposal, and evolutionary development (if any)

(DI-SESS-81248B) Interface Control Document

3.3.10 Quality Assurance: The contractor shall maintain a Quality Assurance (QA) plan/policy to ensure work performed under this contract complies with the performance requirements of the ID/IQ TO, and per FAR Part 46.105. The plan shall specify contractor procedures to identify and prevent, and assure non-reoccurrence of QA issues. The contractor shall identify procedures specific to the requirements of each ID/IQ TO.

3.3.11 Configuration Management: The contractor shall maintain a configuration management plan/policy to ensure work performed under this contract complies with the performance requirements of this ID/IQ TO and MIL-HDBK-61A. The plan shall specify contractor procedures to identify and prevent, and assure non-reoccurrence of configuration management issues. The configuration management efforts for this ID/IQ TO shall include:

a. Identifying, documenting and verifying the functional and physical characteristics of an item.

b. Recording the configuration of an item.

c. Controlling changes to an item and its documentation.

d. Providing a complete audit trail of decisions and design modifications.

3.3.11.1 Engineering Change Proposals (ECP): 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), including changes to the PWS, CDRL, the contract schedule, and the general provisions of the contract.

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

3.3.11.2 Engineering Change Proposal Review: In coordination with the Government, the contractor shall hold a requirements review on all proposed changes prior to the submittal of the ECP 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, or a formal meeting at an agreed to location. All appropriate parties shall be in attendance in order to conduct a thorough, effective review. Minutes shall be an historical record to allay any miscommunications during this IPT.

3.3.11.3 Variances: The contractor shall document the rationale and the potential impact of any variance. The contractor shall obtain approval before varying from any Government-controlled baseline.

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

3.4 Specialty Engineering: The contractor shall provide Supportability Engineering, Reliability, Availability and…