N61340-13-R-1057_Amend_0001.doc

SECTION SF 30 BLOCK 14 CONTINUATION PAGE

SUMMARY OF CHANGES

SECTION J - LIST OF DOCUMENTS, EXHIBITS AND OTHER ATTACHMENTS

The following have been modified:

ATTACHMENT 10 SAMPLE TASK 1

Sample 1

Statement of Work

For LVCMS ASW VAST

1.

SCOPE

This Statement of Work (SOW) establishes the requirements for the tasks to produce and integrate the MH-60R Air Crew Tactical Team Trainer (RACT3) training system that will provide an integrated training capability that supports the MH-60R community in Anti-Submarine Warfare (ASW) proficiency. It also establishes the requirements for products to be provided to the LVCMS ASW VAST Training Systems Integrated Product Team (IPT). The SOW will establish system requirements that will directly and positively impact the ASW proficiency of MH-60R aircrew. The MH-60R Air Crew Tactical Team Trainer (RACT3) training device will provide active, passive and multi-static acoustics training in a deployable PC based simulation for the MH-60R ASW tactical nucleus (Pilot, Co-Pilot, and Sensor Operator) and is also configured with an Instructor Operator Station (IOS). It will leverage existing simulations to minimize the development effort in order to accelerate a solution for the ASW proficiency gap well inside the time-line that would be provided by the Program Objective Memorandum (POM) process. The tasks required in this SOW are within the scope of the LVCMS ASW VAST (ID/IQC) N61340-13-R-1057 SOW PDX13EE02. Each of the main requirement paragraphs in this SOW contains a reference to the paragraphs of the LVCMS ASW VAST (ID/IQC) SOW PDX13EE02, which authorize the required task.

1.1

BACKGROUND

The Navy has requirements for the design, fabrication, test, development and lifecycle modification of the LVCMS ASW VAST training systems to include aircraft, surface, sub surface ships or combat systems which, when in a networked environment, allow for integrated mission training. The RACT3 will be part of the LVCMS and ASW VAST family of training systems.

2.

APPLICABLE DOCUMENTS

The following documents form a part of 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 this SOW take first precedence. Nothing in this SOW, however, supersedes applicable laws and regulations, unless a specific exemption has been obtained. American National Standards Institute (ANSI) information and documents can be found at website http://www.ansi.org. Institute of Electrical and Electronics Engineers (IEEE) information and documents can be found at website http://www.ieee.org.

2.1 Government Documents

Department of Defense (DOD) and Department of the Navy (DON) Security and Information Assurance (IA) Instructions, Handbooks, Guides, and Policy Documents:

a.

DODI 8500.2 – Information Assurance (IA) Implementation, dated 6 February 2003 b.

ISA Security Technical Implementation Guide (STIG) – Application Security and Development STIG c.

DODI 8510.01 – Information Assurance Certification and Accreditation Process (DIACAP) 28 November 2007 d.

DON DIACAP Handbook (Unnumbered) – DON DOD Information Assurance Certification and Accreditation Process (DIACAP) Handbook series, dated 15 July 2008 e.

DoD 8570.01-M - Information Assurance Workforce Improvement Program dated 19 December 2005 (Incorporating Change 2, dated April 20, 2010) f.

DoD 5220.22-M – National Industrial Security Program Operating Manual (NISPOM), dated 28 Feb 2006

The preceding documents are downloadable from:

http://nawctsd.navair.navy.mil/Resources/Library/IA/Index.cfm and DoD STIGs guides are at http://iase.disa.mil/

Other Publications:

NAWCTSD Documents:

a.

Active Processor (AP) Module Interface Design Document (IDD) Version 2.2.2.0 (Attachment 1) b.

Passive Generator (PG) IDD Version 3.1.6 (Attachment 2) c.

LVCMS ASW VAST (ID/IQC) SOW PDX13EE02

2.2 Non-Government Documents

INDUSTRY STANDARDS

American National Standards Institute (ANSI)/American Society for Quality (ASQ)

ANSI/ASQ Q9000-2005

Quality Management Systems - Fundamentals and Vocabulary

ANSI/ASQ Q9001-2008

Quality Management Systems - Requirements

ANSI/ASQ Q9004-2009

Quality Management Systems - Guidelines for Performance Improvements

(Copies of the above documents are available from www.ansi.org or Global Engineering Documents, 15 Inverness Way, East Englewood, CO 80112.)

ANSI/Electronic Industries Alliance (EIA)

ANSI/EIA-649-A 2004

National Consensus Standard for Configuration Management

(Copies of the above document are available from www.ansi.org or Global Engineering Documents, 15 Inverness Way, East Englewood, CO 80112.)

ANSI/Institute of Electrical and Electronics Engineers (IEEE)

ANSI/IEEE Std 1008-1987

IEEE Standard for Software Unit Testing

IEEE Std 1233-1998 Edition (R2002)

IEEE Guide for Developing System Requirements Specifications

IEEE/EIA 12207.1-1997

Standard for Information Technology – Software Life Cycle Process – Life Cycle Data

IEEE Std 12207-2008, 2nd Edition Systems and Software Engineering – Software life cycle processes

IEEE Std 15288-2008, 2nd Edition Systems and Software Engineering – System Life Cycle Process

IEEE Std 15939-2008

Adoption of ISO/IEC 15939:2007 - Systems and Software Engineering - Measurement Process

(Copies of this document are available from www.ieee.org or IEEE Service Center, 445 Hoes Lane, Piscataway, NJ 08854-1331.)

International Organization for Standardization/International Electro-technical Commission (ISO/IEC)

ISO/IEC 27002:2005

Information technology - Security techniques - Code of practice for information security management (Redesignation of ISO/IEC 17799:2005)

(Copies of this document are available from http://www.ansi.org)

High Level Architecture (HLA) Interface Specifications (obtainable by email to HLA@dmso.mil) a.

HLA Interface Specification Annex B: C++ API b.

HLA Interface Specification Version 1.3 c.

HLA Object Model Template Specification (Version 1.3) d.

HLA Rules (Version 1.3)

3.

REQUIREMENTS

3.1 General

NAWCTSD will oversee the program/engineering management, systems engineering, software engineering, subject matter experts, testing, and configuration management for the procurement of RACT3. All materials developed under this SOW for RACT3 development, including final hardware, software, documentation, will be property of the Government. The RACT3 training system may be located in various locations, locally, nationally, and/or internationally. The contractor shall provide the design and capability for the RACT3. This capability shall include the use and implementation of the Aircraft Operational Program (AOP). The system shall include the capabilities for the Pilot, Co-Pilot, and Sensor Operator. There shall be an Instructor Operator Station (IOS) with capabilities for standalone, High Level Architecture (HLA), Navy Continuous Training Environment (NCTE), and Navy Aviation Simulator Master Plan (NASMP) functionality. Operator Station capability shall include the use of all airborne sensors to include: sonobuoys, Airborne Low Frequency System (ALFS) (Dipper), and radar.

3.1.1 Program and Engineering Management

The contractor shall provide program management necessary to ensure effective cost, schedule and technical performance under this contract. All engineering management processes shall be coordinated and approved via the IPT process, defined below. The contractor shall monitor program status in sufficient detail to permit understanding of program progress and risks with respect to achievement of planned milestones and activities, planning, costs, the RACT3 requirements, and design (hardware and software), problem areas, and planned corrective action. This status information shall be made available for review during the IPT meetings. The contractor shall provide a risk management planning process for this contract that identifies how key technology risks, planned risk mitigation activities, fallback options in case of insurmountable difficulty, and decision points in the program schedule will be made. (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.1.4.2). The contractor shall measure, monitor and assess the progress of all the work performed and costs incurred under the contract. The contractor shall prepare the Contractor’s Progress, Status, and Management Report (CPSMR) in accordance with (IAW) the CDRL B001. (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.1.4)

3.1.1.1 Integrated Product Teams (IPT)

The IPT will consist of Government and contractor personnel and have a Government chair. The contractor shall employ an integrated product and process development methodology in its design, integration, and assembly of the RACT3 system. (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.1.4.5)

3.1.1.2 Work Planning and Scheduling

The contractor shall develop, document, implement, control, and maintain an Integrated Program Management Report (IPMR) that presents the contractor’s and subcontractor’s plans and schedules to meet the requirements of the contract. The contractor shall include in the IPMR and IPT meetings any proposed changes to the initial schedule. The reporting shall include sufficient information to allow for a thorough analysis of performance. The contractor shall capture all data required to accurately report, to the Government, the cost of this effort. The contractor shall maintain the IPMR for tracking status. The contractor IPMR shall be submitted IAW CDRL B005. (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.1.4.1)

3.1.1.3 Meetings, Conferences, and Reviews

The contractor shall attend and participate in all meetings and conferences to be conducted throughout the entire contract. The meetings shall be scheduled on mutually agreeable dates, times and places to effect efficient communication on various matters. The contractor shall prepare the Conference Agenda for conferences and reviews IAW CDRL B002. Upon completion of each meeting and conference, the contractor shall submit Conference Minutes IAW CDRL B003.

3.1.1.3.1 IPT Meetings

The contractor shall attend and participate in IPT meetings to be conducted weekly throughout the period of performance. The IPT meetings shall be scheduled on mutually agreeable dates and times. IPT meetings shall be held at NAWCTSD, but may be attended via telecon when travel is not feasible to effect efficient communication on various matters.

3.1.1.3.2 Documentation

The contractor shall assist in writing and maintaining documentation as specified in section 3.2 to support development, maintenance, installation and use of the RACT3 training system. Documentation shall also include the use of any tactical software and the capabilities included or excluded with this tactical software.

3.1.1.4 Security

The contractor shall comply with all the security and IA requirements identified in LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.1.6 and 3.1.7.

3.1.2 Travel

Travel may be required to various sites periodically to complete the tasks. These sites include: Patuxent River, MD, Orlando, FL, Naval Air Station (NAS) Jacksonville, FL, Naval Station, Mayport, FL, and NAS North Island, San Diego, CA. The contractor shall perform all travel in accordance with the contract provisions.

3.2 Detailed Requirements

3.2.1 RACT3 System and Platform Requirements CLIN 0002 (CPFF)

The paragraphs in the sections below provide the scope of detailed requirements. (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.2). This entire trainer system shall be priced as a Cost Plus Fixed Fee (CPFF) for all items within 3.2.1.1. The additional requirements for pricing are as follows:

a.

The Naval Air Station (NAS) Mayport, FL site has the following characteristics:

1) 120v 60 Hz power with an electrical power distribution of 200 amps. There is conditioned power and does not require the use of additional power conditioning or surge protection. Heating, Ventilating, and Air Conditioning (HVAC) shall be provided by the Government and shall be under a separate contract.

2) Room dimensions are: 30ft by 20ft with a raised floor. Cabling shall be run thru the raised floor.

3) The tactical software shall be the MH-60R AOP 86 Mod29 version and will not change during the development and delivery.

3.2.1.1 System Requirements

3.2.1.1.1 Hardware

The RACT3 system hardware design shall support system portability. The system and associated packaging crates, shipping crates, and transport cases shall be deployable via a standard single C-9 Air Force pallet. Hardware shall be limited to the least number of components to support the software requirements. The use of a rack configuration shall be considered a single component, whereas standalone computers and station units shall each be considered individual components. Hardware interconnection wiring design shall incorporate the minimum number of cables and connections. Cabling to the man-machine interface device for each station, including keyboard, video, and pointing device (mouse or trackball), shall be extensible to lengths up to 200 feet from the main computing system. Hardware design shall incorporate the use of regulated and conditioned power from multiple sources. All power shall be regulated to the output of 120 volt, 60 hertz. The system shall be designed to accommodate full system operation under both worst case surge and steady state load without anomaly. The system shall provide for service in the event of power loss for a minimum of ten minutes in order to allow for controlled shutdown of system hardware and software without data loss or system damage. The hardware design shall be flexible to meet different training system site layouts with a maximum of 200 feet between connected stations and units. No single unit shall be further than 200 feet from any other unit. Station hardware shall incorporate human factors design characteristics equivalent to the system configurations on the MH-60R aircraft. Hardware shall be designed such that it can be assembled within two hours by Fleet users at the E5 Naval Air crewman (AW) level without assistance. All interconnection wiring and cabling shall be coded and labeled for each connection. The contractor shall provide hardware design documentation in accordance with the Trainer Engineering Report document CDRL A00H. The Trainer Engineering Report shall include power, HVAC characteristics.

3.2.1.1.2 Software

Software reuse shall include but is not limited to: Government Furnished Information (GFI) Passive Generator (PG) and Active Processor (AP) IAW the GFI IDDs. RACT3 shall use open computer architectures and high-level software languages for all computational and data processing computer systems to the maximum extent practical. Where feasible, the RACT3 shall utilize Commercial and Non-Developmental Items (CaNDI) software applications to reduce developmental cost, shorten lead-time and reduce overall life cycle costs. The RACT3 shall utilize the Tactical Software for the Airborne Operational Program (AOP). Source code development shall emphasize re-use and be modular, well-commented, and efficient. The contractor shall provide all developmental and runtime software and licenses upon delivery. The integrated and enhanced technologies used for real-time stimulation of the RACT3 acoustic operator stations shall be able to support training of perishable skills including use of controls, deployment of system assets consistent with mission usage, and classification of the contact through bi-static active signal analysis, mono-static signal analysis and passive signature analysis. RACT3 shall support training of non-acoustic ASW sensors/systems. The contractor shall ensure that all data, including volatile data, be saved and recovered prior to all source code updates. The contractor shall coordinate these efforts with the Government IPT members.

3.2.1.2 Network Requirements

The RACT3 shall be interoperable and compliant with the Navy Continuous Training Environment (NCTE) and the Naval Aviation Simulation Master Plan (NASMP) via NCTE using Joint Semi Automated Forces (JSAF) Navy Training Baseline (NTB). Navy Warfare Development Command (NWDC) will certify NCTE compliance, while NAWCTSD will certify NASMP compliance.

3.2.2 Systems Engineering

The contractor shall utilize systems engineering define requirements, design, integrate and test the RACT3 training system to support rehearsal of Command and Control, Tactics, Techniques, and Procedures. The RACT3 training systems shall provide individual, coordinated, and integrated training with sufficient fidelity to allow crews to perform the tasks realistically and dynamically. The contractor shall develop the following stations: Instructor Operator Station (IOS), Pilot, Co-Pilot, and Sensor Operator (SO) stations that support the capability for sonobuoy processing. This capability will include the use of the Acoustic Generator (AG) or equivalent capability, Active Processor (AP) or equivalent capability for tactical software simulation, and capable of supporting the MH-60R Airborne Low Frequency Sonar (ALFS) Dipper. Sonobuoy stimulation shall include capabilities of the AN/SQQ-57E Directional Frequency Analysis and Recording (DIFAR) and AN/SQQ-62D series Directional Command Active Sonobuoy System (DICASS). SO and Co-Pilot capability shall include the capability of the system for sonobuoy processing to include all Verniers, and band processing. (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.2.2)

3.2.3 Detailed RACT3 System and Platform Requirements

The paragraphs in this section provide the scope of requirements for a sample task. The contractor shall perform the following: (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.2)

3.2.3.1 Overall System Requirements

a.

Emulate or simulate the operator interfaces, data processing, and communications systems of the real-world mission systems b.

Provide an interactive virtual battlespace environment with friendly, threat, and neutral forces, weather, bathymetry, sea state, terrain, relevant cultural features, weapons system, and weapons effect that are accurately depicted real-time c.

Provide fair fight interactions via the use of correlated environmental, contact, and sensor representations in the virtual training environment d.

Each trainer operator station shall represent its respective real-world system and station and accurately portray a visually and functionally realistic operator display e.

Be capable of supporting any tactically correct combinations of aircraft, surface, and subsurface unit configurations during a training exercise f.

Emulate the effects of battle damage on the characteristics and capabilities of the virtual and constructive platforms, behaviors, sensors, and weapon systems g.

Provide weapon systems models which are affected by atmospheric and bathymetric conditions h.

Provide weapon systems models that use appropriate signature data to detect and engage targets i.

Represent accurate Probability-of-acquisition (Pa), Probability-of-hit (Ph), and Probability-of-kill (Pk) models for all required air, surface, and subsurface platforms, sensor systems, and weapons systems

3.2.3.2 Instructor Operator Station (IOS) Requirements

a.

Use Computer Generated Forces (CGFs) to provide threat, neutral and friendly force representations b.

Provide a transparent utilization of Semi-Automated Forces (SAF) to the trainees participating in the training exercise c.

Provide a capability for real-time monitoring and analysis of team and individual student performance during the scenario execution within a training exercise d.

Provide control of trainee stations (i.e., start, stop, pause, insertion of casualties, removal of casualties, and assignment of scenarios) e.

Provide the ability to author and modify scenarios f.

Perform student recordkeeping and student enrollment functionality

3.2.3.3 Training System Network Requirements

a.

Be interoperable with the Navy Continuous Training Environment (NCTE) b.

Interoperate with Distributed Interactive Simulations (DIS) and High Level Architecture (HLA) Federation networks configured to support a training event c.

Provide voice communications to simulate operational radio networks and intercom systems, and to provide a training exercise management network d.

Provide the instructor a means to filter and select desired communications between multiple stations, suites, or locations

3.2.3.4 After Action Review (AAR) Requirements

a.

Provide an AAR capability to view and analyze results of the training exercise.

b.

Provide the functionality to record and playback eight (8) hours of a single training event for all voice communications c.

Provide the capability to store five (5) training events d.

Provide the capability to establish training checkpoints to demarcate specific points and/or periods of interest e.

Provide a marking and playback function that can run in real time and up to 32 times real time as selected by the instructor f.

Provide the functionality to rapidly reconstruct and debrief an exercise scenario by comparing historical ground truth (entity type, location, course, speed, depth, altitude, key communications, and key mission events) against perceived truth g.

Provide the functionality to display AAR debriefs on a two-dimensional (2D) display with split screen mode h.

Provide functionality to download the AAR to a CD or DVD for later review

3.2.4 Software Development

The contractor shall develop and document a software development program to meet the requirements of this contract. The contractor shall implement and maintain the software development program and its software engineering environment for the duration of the contract. The contractor shall provide software development support for the RACT3 system, which includes: software development, test, integration, and documentation of software. The contractor shall use a high-level programming language. Source code development shall emphasize re-use, and be modular, well-commented, and efficient. The contractor shall provide all developmental and runtime software and licenses at contract completion. (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.2.2.4)

3.2.4.1 Software Deliverables

Software deliverables shall include source code and documentation for the RACT3 components. The contractor shall deliver all software deliverables to the Government facility. The contractor shall deliver the Software Product Specification IAW CDRL A006. Changes to approved software baselines shall require Government authorization. The Government will maintain configuration control of software baselines used during Government testing. The contractor shall demonstrate to the Government that proposed software baseline changes are supported by contractor regression testing. The contractor shall use Software and Firmware Change Requests to request software changes to an approved baseline. The contractor shall prepare the Software and Firmware Change Request IAW CDRL A00J.

3.2.4.1.1 Cold Start Procedures

The contractor shall develop, document, control, maintain, validate and prepare, computational subsystem cold start procedures IAW IEEE/EIA 12207.1-1997, sections 6.7 and 6.13. The contractor shall prepare a cold start procedure for each subsystem or component that is delivered with associated software source code. The contractor shall prepare a cold start procedure for each computational subsystem or component that is composed of contractor developed components (e.g. computer hardware, operating system, and application software), which are then integrated into the RACT3 system. The contractor shall provide RACT3 system cold start build procedures to include data recovery and installation based on the current approved hardware configuration and software updates. The contractor shall not use any type of disk image to accomplish a cold-start without prior approval of the Government. The contractor shall develop cold start procedures: (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.2.2.4.6.1) a.

For configuring applicable computer hardware settings such as in a BIOS or firmware b.

For installing and configuring each operating system, to include user accounts, network connectivity, device drivers, and information assurance controls for the training application c.

For installing and configuring each development system operating system and software tools, to include user accounts, network connectivity, device drivers, and information assurance controls for the development system on which trainer software executables are generated from source code d.

For installing and configuring each software application e.

For installing the deliverable source code f.

For performing a software build(s) where executable program(s) are created from deliverable source code g.

For introducing Government-authorized source code changes; where the existing software build is removed and a new build is created h.

That consist of detailed descriptive action to be performed; the expected result following the action; and an area to document abnormalities, discrepancies, errors, and pass/fail status i.

That ensure that complex sequences of cold-start actions are broken down into discrete steps with explicitly defined control actions and expected results for each test step j.

That can be accomplished by the Government systems engineer, software engineer, or In-Service Engineer (ISE) without referring to external documentation k.

That include listing the physical software media required to perform the cold-start l.

That include Commercial Item software activation data, such as serial numbers and key codes

3.2.4.1.1.1 Installation and Configuration Procedures

The contractor shall develop, document, control, maintain, validate, and prepare the installation and configuration procedures IAW IEEE/EIA 12207.1-1997 sections 6.7 and 6.13. The contractor shall prepare installation and configuration procedures for each computational subsystem acquired as a tightly integrated, ready to use turnkey system. Turnkey describes a Commercial Item that is pre-built, in which everything needed is put together by a vendor and sold as a bundle. Examples of turnkey subsystems could include Commercial Item control loaders, aural cueing, and image generators. The contractor shall develop installation and configuration procedures:

a.

For configuring applicable computer hardware settings such as in a BIOS or firmware b.

For restoring the system software, such as the operating system, applications and data, to the original delivered configuration on a freshly formatted hard drive c.

For configuring the system software for use within the training application, such as user accounts, network connectivity, and information assurance controls d.

That consist of detailed descriptive action to be performed; the expected result following the action; and an area to document abnormalities, discrepancies, errors, and pass/fail status e.

That ensure that complex sequences of installation and configuration actions are broken down into discrete steps f.

That can be accomplished without referring to external documentation g.

That include listing the physical software media required to perform the installation and configuration procedure h.

That includes Commercial Item software activation data, such as serial numbers, license files, and key codes as well as any other pertinent license information

3.2.4.1.1.2 Media and Storage Devices

The contractor shall provide to the Government the blank media and mass storage devices necessary to perform each subsystem cold start and installation procedure. The Government will retain custody and control of the media and storage devices created or used by the Government to accomplish testing. The contractor shall provide the additional media and mass storage devices necessary for the contractor’s internal archiving, development, testing, and other engineering and configuration management (CM) purposes.

3.2.4.1.1.3 Cold Start and Installation Procedure Media

The contractor shall prepare a unique set of physical media for each computational subsystem. The contractor shall prepare the physical media required to perform each subsystem cold-start procedure with labeling that:

a.

Is formatted consistently b.

Is permanently attached to the physical media c.

Identifies the software vendor name d.

Identifies the software product name e.

Identifies the software version number f.

Identifies the software release date g.

Identifies the contractor’s Configuration Control identifier h.

Identifies the total number of media pieces that compose each configured item i.

Identifies the individual piece number within a multiple piece item, such as “Disk 2 of 5” or “DVD 1 of 3”

3.2.4.1.1.4 Automated Processes

The contractor shall document, control, maintain, validate, and deliver all computational automated processes (e.g., scripts, batch files, job control language, kick-start, and slipstreamed media) in the same manner as software items.

3.2.4.1.1.5 Contractor Execution

Prior to the start of each Test Readiness Review (TRR), the contractor shall execute and validate each subsystem cold start and installation procedure. The contractor shall perform the entire cold start and installation procedure, step-by-step as written, and document the results of each step. The contractor shall present the results of each contractor-run cold start and installation procedure to the Government for review at the following TRR event. The contractor shall execute, document, correct and validate each cold start and installation procedure until no discrepancies exist.

3.2.4.2 System Requirements Review/System Functional Review (SRR/SFR)

The contractor shall conduct an SRR/SFR. The SRR/SFR is a multi-disciplined product and process assessment to ensure that the training application under review can proceed into preliminary design, and that all system requirements and derived functional performance requirements are defined and consistent with cost, schedule, risk, and other system constraints. The SRR/SFR shall assess the training application functional requirements and ensure that all required system performance is fully decomposed and is traceable to the functional baseline. At the SRR/SFR, the contractor shall: (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.2.2.7.3) a.

Identify and discuss resource availability to support the schedule b.

Present and discuss a schedule Critical Path c.

Provide current status vs. Critical Path d.

Describe implementation of Software Development Plan e.

Show that all functional requirements are traceable to the system requirements f.

Address the following applicable functional areas:

(1) System Requirements Analysis

(2) System Interface and Design

(3) Interoperability

(4) Information Assurance

(5) Data Management

(6) Test

(7) Configuration Management

(8) Security

(9) Maintenance Management

3.2.4.2.1.1 SRR/SFR Entry Criteria

Entry criteria for the SRR/SFR shall consist of Government concurrence with the following:

a.

Delivery and acceptance (when applicable), IAW CDRL requirements, of all the CDRL items scheduled to be delivered prior to SRR/SFR b.

Contractor submitted SRR/SFR agenda is complete and acceptable c.

IPMR is resourced at reasonable levels with realistic performance expectations d.

Program technical risks identified e.

Program execution risks identified

3.2.4.2.1.2 SRR/SFR exit criteria

Exit criteria for SRR/SFR shall consist of Government determination of acceptable risk in all the SRR/SFR elements listed above, and Government concurrence with the following:

a.

All SRR/SFR issues were captured in Requests for Action (RFAs) and properly adjudicated and assigned b.

All SRR/SFR RFAs were completed (closed) c.

The required technical areas were represented at the review d.

Functional requirements, as disclosed, shall satisfy the training needs e.

System functional definition and functional decomposition is detailed enough to support preliminary detailed design f.

System Functional Baseline has been established to enable preliminary design to proceed under Configuration Management g.

Processes and metrics are in place h.

Risks are known and are manageable for implementation of the functional requirements into a preliminary design i.

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

Program is properly staffed

3.2.4.2.2 In-Process Review (IPR)

The contractor shall conduct monthly IPRs. IPRs shall provide attendees with information regarding the status and planned activities of the program. IPRs shall include the following information: (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.2.2.7.5) a.

Presentations on the status of the overall SOW tasking, including software development, integration and test tasking.

b.

Review of software status c.

Review of the project schedule status d.

Review of project risks

3.2.4.2.3 Preliminary Design Review (PDR)

The contractor shall conduct a PDR in support of the development of the RACT3 training device. The purpose of the PDR is for the Government to formally review the activities and work products generated by the contractor during the performance of the preliminary design stage in order to develop the allocated baseline, and to verify that the approach for the system design or system modification design is ready to proceed into the detailed design phase. The contractor shall present and describe the training application design and program status, and address all design changes made to the preliminary design proposed in the proposal. The following items shall be topics of discussion and presentation at the PDR: (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.2.2.7.6) a.

System hardware and software design, including:

(1) Instructor Operator Station (IOS)

(2) Interoperability design and implementation

(3) Software tools

(4) Use of developmental and Commercial and Non-developmental (CaNDI) software and databases

(5) Trainer databases

(6) Software development files

(7) Hardware and software interfaces

(8) Design modularity and commonality b.

Logistics design aspects and concerns c.

Test and evaluation d.

Security and IA, including systems security design, initial security risk assessment, security test approach, security training approach, and any other security and IA relevant information e.

Program problem and risk areas, recommended solutions, and evaluation of alternatives

3.2.4.2.4 PDR Entry Criteria

Entry criteria for the PDR shall consist of Government concurrence with the following:

a.

SRR/SFR exit criteria have been met b.

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

Allocated baseline has been developed d.

Risk assessments and risk mitigation plans have been developed e.

IPMR shows critical path through Critical Design Review (CDR) f.

Program technical risk is medium or lower g.

Program execution risk is medium or lower h.

PDR agenda has been submitted and accepted

3.2.4.2.5 PDR Exit Criteria

Exit criteria and final acceptance of the PDR shall consist of Government concurrence with the following:

a.

CDRL items that were part of the PDR entry criteria have been satisfactorily discussed b.

Risk assessments and risk mitigation plans have been satisfactorily discussed c.

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

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

Program is properly staffed f.

PDR action items have been successfully resolved and closed g.

PDR presentation materials are available h.

Per the IPMR, an executable schedule has been presented i.

PDR minutes have been submitted and accepted j.

Allocated baseline has been established

3.2.4.3 Critical Design Review (CDR)

The contractor shall conduct a CDR in support of the development of the RACT3 training device. The purpose of the CDR is for the Government to formally review the activities and work products generated by contractor during the performance of the critical design stage in order to develop the product baseline, and to verify that the training application is ready to proceed into the hardware-software coding, assembly, and integration phase. The contractor shall present and describe the finalized system design and program status, and address all design changes made since the PDR. The following items shall be topics of discussion and presentation at the CDR: (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.2.2.7.7) a.

System hardware and software design, including:

(1) Instructor Operator Station (IOS)

(2) Interoperability design and implementation

(3) Software tools

(4) Use of developmental and Commercial and Non-developmental (CaNDI) software and databases

(5) Trainer databases

(6) Software development files

(7) Hardware and software interfaces

(8) Design modularity and commonality b.

Logistics design aspects and concerns c.

Test and evaluation d.

Security and IA, including updates to the system security design, security risk assessment, security test approach, security training approach, and any other security and IA relevant information e.

Program problem and risk areas, recommended solutions, and evaluation of alternatives

3.2.4.3.1 CDR Entry Criteria

Entry criteria for the CDR shall consist of Government concurrence with the following:

a.

PDR exit criteria have been met 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 developed 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.

Trade-off analyses have been completed g.

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

Facility planning has been completed i.

IPMR shows critical path through testing j.

CDR agenda has been submitted and accepted

3.2.4.3.2 CDR Exit Criteria

Exit criteria and final acceptance of the CDR shall consist of Government concurrence with the following:

a.

CDRL items that were part of the CDR entry criteria have been satisfactorily discussed b.

Updated risk assessments and risk mitigation plans have been satisfactorily discussed Risks and their respective mitigation plans are in place and manageable for implementation of the functional requirements into a final design c.

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

Program is properly staffed e.

CDR action items have been successfully resolved and closed f.

CDR presentation materials are available g.

Per the IPMR, an executable schedule has been presented h.

CDR minutes have been submitted and accepted i.

Product baseline has been established

3.2.4.4 Information Assurance

The contractor shall provide input for Information Assurance (IA) accreditation documentation to be developed and maintained by the Government. The contractor shall test and certify that each contractor developed RACT3 system component and sub-component software functions as designed in a properly secured operating system environment and is free of elements that might be detrimental to the secure operation of the resource operating system prior to delivery of those components and sub-components to the Government. The contractor shall use DoD-authorized assessment tools to perform IA testing (e.g., Security Technical Implementation Guides (STIGs), Retina, Gold Disk), document, verify, and validate each component and sub-component software IA configuration. The contractor shall document the IA compliance results in the Information Assurance Test Report IAW CDRL A00G. The contractor shall provide RACT3 components that meet the Department of Defense Information Assurance Certification and Accreditation Process (DIACAP) requirements for system accreditation. The contractor shall design, develop, document, integrate, verify, and deliver security architecture for the training application that satisfies the System IA controls as defined in DoDI 8500.2 for a Mission Assurance Category (MAC) III, Classified device, and meets the security and IA performance requirements. (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.2.2.9)

3.2.4.4.1 IA Certification and Accreditation Support

The contractor shall support the IA certification process IAW DoDI 8510.01 and the implementing guidance contained in the DoN DIACAP Handbook. The contractor shall prepare the Scientific and Technical Reports (DIACAP Certification and Accreditation (C&A) Package) IAW the CDRL A00D.

3.2.4.4.2 IA Software Integrity Testing and Certification

The contractor shall test and certify that the training application software functions as designed in a properly secured operating system environment and is free of elements that might be detrimental to the secure operation of the resource operating system, as described in DoDI 8500.2. The contractor shall provide Vendor Integrity Statements (VIS) for each system software application. Commercial Item software does not require a VIS. The contractor shall prepare the Scientific and Technical Reports (VIS for Software) IAW the CDRL. The contractor shall prepare the Scientific and Technical Reports (Vendor Integrity Statements for Software) IAW CDRL A00E.

3.2.4.4.3 IA Compliance

The contractor shall test, verify, and document that the security architecture of the training application is in compliance with the security requirements and IA controls identified in DoDI 8500.2 for a MAC III, Classified systems. The contractor shall use DoD-authorized assessment tools to perform IA testing (e.g. Retina, Gold Disk), document, verify, and validate each applicable operating system IA configuration. Prior to testing, the Government will provide a list of assessment tools that the Government intends to use during testing. The contractor shall document the IA compliance results in the DIACAP C&A Package cited above in 3.1.2.1. The contractor shall work with NAWCTSD during coordination efforts with the Designated Accrediting Authority to support NAWCTSD in obtaining a system Authorization to Operate (ATO) concurrent with delivery of the RACT3 system.

3.2.4.4.4 IA Vulnerability Management Program (IAVMP)

The contractor shall incorporate the applicable DoD and DoN IAVMP messages issued through Government Preliminary Inspection (GPI). The contractor shall document the unincorporated IA Vulnerability Alerts (IAVAs), IA Vulnerability Bulletins (IAVBs), and IA Vulnerability Technical Advisories (IAVTAs). The contractor shall provide justification for each unincorporated IAVMP message (i.e., describe the specific negative impact the IAVMP message incorporation would have on trainer operation). The contractor shall document the information resulting from this task in the DIACAP C&A Package cited above in 3.1.2.1.

3.2.4.5 System Test and Evaluation (T&E)

The contractor shall plan, coordinate, establish, and implement a comprehensive T&E program that shall be designed to verify that the RACT3 training system, which includes the integration of all subsystems and equipment meet the technical and operational requirements as stated in this SOW. The contractor shall provide a testing effort that shall consist of a logical sequence of component, subsystem and system level hardware and software tests. The contractor shall make their testing approach integral to the Integrated Product Team (IPT) process. The contractor shall use the appropriate IPT to analyze, define, correct and re-qualify faulty design. The contractor shall support NCTE testing with RACT3 to ensure compliance and interoperability with the NCTE. The contractor shall support the conduct of tests on the dates established by the IPMR. Test events and dates will exist for each of the independent life-cycle development spiral phases and their corresponding configuration managed HW and SW baselines. (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.2.2.10)

3.2.4.6 Responsibility for Tests

Unless otherwise specified herein, the contractor shall perform the specified test and inspections. The Government reserves the right to perform tests and inspections that are deemed necessary to ensure that delivered supplies and services conform to the contract requirements.

3.2.4.7 Test Authority

The contractor shall record the test results during contractor’s inspections. A PCO representative will certify the contractor’s test results. A PCO representative will record the Government’s inspection and test results.

3.2.4.8 T&E Program Planning

The contractor shall develop and document the structure and objectives of the trainer T&E program. The contractor shall continuously reassess and refine the T&E program as trainer and trainer modifications development, production, and testing progresses. When applicable, a baseline preliminary Test & Evaluation Master Plan (TEMP), prepared by the Government, will be provided as an attachment to the contract. The contractor shall update the TEMP throughout the contract to reflect changes in T&E concepts, test responsibilities, mission and systems descriptions, T&E ground rules, schedules, documentation, and resource requirements. TEMP review shall be an agenda item at each scheduled requirements, design, progress, and test readiness reviews. The contractor shall prepare the Revisions to Existing Government Documents (TEMP) IAW CDRL A008.

3.2.4.9 Test Resources and Facilities

The contractor shall furnish the inspection and testing equipment and personnel required to ensure that the RACT3 training system meets the requirements specified. The contractor shall ensure that all contractor personnel, test equipment, other supporting equipment, spare assemblies and parts, test and data logs, and other items necessary for testing are available for the start and during all phases of testing. Testing shall be conducted at NAWCTSD.

3.2.4.10 Test Methods

Tests shall be performed IAW the Government-accepted Trainer Test Procedures (TTP) document and other Government-accepted test plans as documented in the TEMP. Test, examination, demonstration, inspection, and verification procedures shall be documented in the TTP. Any revisions to the TTP shall be provided to the appropriate IPT chair prior to final system testing. The test methods and procedures shall be written so that a qualified technician can perform the tests. The system cold start procedures, developed in accordance with SOW paragraph 3.2.4.1.1, shall be included as part of the TTP. When two or more quantitative readings are required simultaneously, the test method shall provide an automated means for data collection to the maximum extent practicable. The cases where this automated data collection is not practicable shall be authorized by the T&E IPT and documented in the TEMP. No calculations, extrapolations, or other mathematical processing shall be required, or allowed, as part of an ongoing test to arrive at the expected results, unless authorized by the T&E IPT and documented in the TEMP. Test results shall be documented in the Test/Inspection Report (T/IR). Test, examination, demonstration, inspection, and verification results shall be documented in the Test/Inspection Report (T/IR). The contractor shall prepare the TTP IAW CDRL A009 and the Test/Inspection Report IAW CDRL A00F.

3.2.4.11 Test Log

The contractor shall maintain a Test Log of all subsystem and system tests conducted. Entries into the test log shall begin with the start of contractor/subcontractor engineering verification testing and shall continue until the completion of testing. The test log shall show by date, the equipment activated, maintenance performed, including adjustments and alignments, equipment failures, redesign, and replacement. The contractor shall present the information in the log to help the government technical representative determine that the maintenance or replacement has not invalidated previously completed tests. The log shall be made available to the PCO or Government technical representative upon request. All changes made in the programming, or adjustments during the testing program shall be recorded in the contractor's test log. All tests conducted prior to such changes shall be repeated unless the PCO or the PCO’s authorized representative determines that such changes have not invalidated the related test data. The testing program shall be defined and documented in the TEMP as required by the CDRL.

3.2.4.12 T&E Deficiency Reporting (DR) System

The contractor shall establish and implement a Deficiency Reporting System for the identification, tracking, and resolution of hardware and software problems (including tactical subsystem) discovered during the Conformance Inspections. In addition, the Deficiency Reporting System shall be used to track documentation problems including Technical Documentation (TD) deficiencies. The Deficiency Reporting System shall provide the Government with accessibility and visibility to all DRs and tracking documents. The contractor shall document deficiencies IAW the TEMP. (Ref: LVCMS ASW VAST ID/IQC SOW PDX13EE02, para. 3.2.2.10.7)

3.2.4.12.1 Deficiency Report (DR) Categories

DRs shall be categorized as Part I through Part III. During the Conformance Inspections, the Government will assign DR categories as deemed appropriate. The following are the definitions of the DR categories:

a.

Part I* (safety/critical) - Jeopardizes safety. Deficiency results in safety hazard(s) to personnel and/or equipment. Testing shall not proceed until the safety hazard is satisfactorily resolved, as determined by the Government.

b.

Part I (critical) - Prevents the accomplishment of an operational or mission essential training system capability, or jeopardizes security, life cycle support, or other critical requirements, as determined by the Government. Deficiency results in significant degradation in mission accomplishment, technical performance, or supportability. Acceptable workarounds may not be available or may have negative consequences, as determined by the Government.

c.

Part II (major) - Adversely affects the accomplishment of an operational or mission essential training…