Attach_1_SOW_v3.pdf

N00024-15-R-6270

ATTACHMENT 1

STATEMENT OF WORK

FOR THE

LIGHT WEIGHT LOW COST CONFORMAL ARRAY (LWLCCA) AND LOW COST CONFORMAL

ARRAY (LCCA)

SOFTWARE DEVELOPMENT AND ENGINEERING SERVICES

PREPARED BY

PROGRAM EXECUTIVE OFFICE, SUBMARINES (PEO SUB)

PMS401

12 May 2015 ii

TABLE OF CONTENTS

1.0 SCOPE

1.1 COLLABORATIVE DEVELOPMENT ENVIRONMENT

2.0 REFERENCED DOCUMENTS

2.1 ORDER OF PRECEDENCE

2.2 GOVERNMENT DOCUMENTS

2.3 NON-GOVERNMENT DOCUMENTS

3.0 REQUIREMENTS

3.1 GENERAL REQUIREMENT

3.1.1 Program Management

3.1.1.1 Contract Work Breakdown Structure (CWBS)

3.1.1.2 Integrated Program Management Report (IPMR)

3.1.1.3 Subcontract Management and Control

3.1.1.4 Program Risk Analysis

3.1.1.5 Program Management Reviews

3.1.1.6 Technical Reviews

3.1.1.7 Integrated Product Team (IPT)

3.1.1.8 Coordination

3.1.1.9 Data Management

3.1.1.9.1 Digital Data Management

3.1.1.9.2 Internal Data / Data Access

3.1.1.10 Government Furnished Information (GFI)

3.1.1.11 Government Furnished Property/Equipment/Material (GFP/E/M)

3.1.2 Systems Engineering

3.1.2.1 Systems Engineering Management

3.1.2.2 Open Systems Architecture Approach

3.1.2.3 Specification Requirement Verification Matrix (SRVM)

3.1.2.4 System Engineering and Design Analyses

3.1.2.5 Design Analysis

3.1.2.5.1 Failure Modes, Effects, and Criticality Analyses (FMECA)

3.1.2.5.2 Failure Reporting Analysis and Corrective Action System (FRACAS)

3.1.2.6 Information Assurance (IA)

3.1.2.7 Test and Evaluation Program Plan (TEPP)

3.1.2.8 Integrated Logistics Support (ILS)

3.1.2.8.1 Supportability Analysis

3.1.2.8.2 Interactive Electronic Technical Manual (IETM)

3.1.2.9 Configuration Management and Documentation

3.1.2.9.1 Software Baseline Identification

3.1.2.9.2 Configuration Control

3.1.2.9.3 Configuration Audits

3.1.2.9.4 Configuration Status Accounting

3.1.2.10 Problem Reporting System

3.1.2.11 Engineering Change Documentation

3.1.2.11.1 Engineering Change Proposal (ECP)

3.1.2.11.2 Class II ECPs, Minor RFVs

3.1.2.11.3 Request for Variance (RFV)

3.1.2.11.4 Revision to ECPs/RFVs

3.1.2.11.5 Classified Data

3.1.2.11.6 Requests for Waivers

iii

3.1.2.11.7 Specification Change Notices (SCNs)

3.1.2.11.8 Notice of Revision (NOR)

3.1.2.11.9 Engineering Change Instruction

3.1.2.12 Quality Assurance (QA)

3.1.2.13 Studies / Analyses

3.1.2.14 Technical Data Package (TDP)

3.2 SOFTWARE DEVELOPMENT

3.2.1 Software Engineering

3.2.1.1 Software Design Requirements

3.2.1.2 Interface Management and Documentation

3.2.1.3 Software Version Description (SVD)

3.2.2 Integration and Test Engineering

3.2.3 Quality Assurance Testing

3.3 ENGINEERING SERVICES

STATEMENT OF WORK

FOR THE

LIGHT WEIGHT LOW COST CONFORMAL ARRAY (LWLCCA) AND LOW COST CONFORMAL

ARRAY (LCCA)

SOFTWARE DEVELOPMENT AND ENGINEERING SERVICES

1.0 SCOPE

This Statement of Work (SOW) defines the efforts required for the program management, engineering, software development, logistics, configuration management, software integration test and evaluation, and

Information Assurance (IA), of the Light Weight Low Cost Conformal Array (LWLCCA) and Low Cost Conformal

Array (LCCA) systems. This effort includes exploring existing and new approaches to sensor processing and developing new or augmenting existing capabilities as required to meet the acoustic processing needs for the Navy.

The efforts defined herein are applicable to SSN688I, SSN21, and SSN 774 Class Submarines.

The Contractor shall develop, test, and deliver a common operational LWLCCA and LCCA Software to meet all requirements specified in the “AN/BQQ-10(V) Light Weight Low Cost Conformal Array (LWLCCA) and

Low Cost Conformal Array (LCCA) In-Board Processing Specification” (PMS401-LCCASpec-01). The delivery and acceptance of the common LWLCCA and LCCA Software shall be contingent on successful completion of qualification and acceptance testing (see Sections 3.2.2 and 3.2.3.).

Engineering Services will be subject to specific information identified in Technical Instructions issued in accordance with the Special Contract Requirement entitled “TECHNICAL INSTRUCTIONS.”

1.1 COLLABORATIVE DEVELOPMENT ENVIRONMENT

The Contractor is required to deliver the common LWLCCA and LCCA Software for TI-18 and TI-20 as

GFE to Acoustic Rapid Commercial-off-the-shelf Insertion (A-RCI) System Integrator for system integration and shipboard installation. There are also other industry partners whom provide engineering services and support of the

A-RCI Sonar System. The Contractor shall work in a collaborative environment with a consortium of Navy, Navy laboratories, Academia, A-RCI Prime System Integrator, Ownship Monitoring Ship (OMS) Developer, Common

Acoustic Cabinet (CAC) Developer, and other industry partners to ensure continued success of the program. The

Contractor shall identify his approach to be used to support the Open Systems Architecture” (See Section 3.1.2.2) to enable third party applications and allow for the efficient integration of improvements with the Submarine Acoustic

Systems. The Contractor shall leverage past experience involved in similar efforts and indicate the approach that will be used in delivering this effort.

Based on the rapid development cycle for A-RCI builds, it is highly encouraged that the Contractor maintains a constant presence at the A-RCI System Integration facility to support all integration efforts, Fleet support issues, and common LWLCCA and LCCA system development.

2.0 REFERENCED DOCUMENTS

The documents listed below in Sections 0 and 2.3 are incorporated by reference and applicable to the extent set forth in this SOW. These documents are provided as guidance when developing the documentation for the

LWLCCA and LCCA subsystem.

2.1 ORDER OF PRECEDENCE

The order of precedence shall be in accordance with FAR 52.215-8.

2.2 GOVERNMENT DOCUMENTS

PMS401-LCCASpec-01

Rev ---

DD MMM 2014

AN/BQQ-10(V) Light Weight Low Cost Conformal Array

(LWLCCA) and Low Cost Conformal Array (LCCA) In-Board

Processing Specification

MIL-HDBK-470A

Thru Notice 2

31 May 2012

Designing and Developing Maintainable Products and

Systems, Volume I

MIL-HDBK-502A

08 March 2013

Department of Defense Handbook Product Support Analysis

MIL-PRF-29612B

Thru Notice 2

20 June 2011

Training Data Products

MIL-STD-881C

3 October 2011

Work Breakdown Structures for Defense Materiel Items

MIL-STD-882E

11 May 2012

Department of Defense Standard Practice: System Safety

MIL-STD-1472G

11 January 2012

Department of Defense Design Criteria Standard, Human

Engineering

MIL-STD-31000A

26 February 2013

Technical Data Packages

NDMS-100001-000

05 Oct 2009

Technical Manual Contract Requirement (TMCR), Interactive

Electronic Technical Manual (IETM) for the A-RCI Program

NAVSEA ltr 5510, Ser/TSUB-0140

24 June 2005

Team Submarine Information Security Policy

NAVSEA PMS401 IUID Plan

03 May 2012

PMS401 Submarine Acoustic Program Office AN/BQQ-10(V)

SONAR Set Item Unique Identification Execution Plan

NUWC-NPT Tech Memo 14-003

Rev G

13 May 2014

Acceptance Test Plan for Submarine Sonar

NUWC-NPT Tech Memo 14-059

10 September 2014

AN/BQQ-10 Sonar System Integration and Testing Process

PEO IWS / NAVSEA Technical

Review Manual (TRM)

Version 2.0

18 December 2009

Technical Review Manual (TRM)

Program Executive Officer Integrated Warfare Systems (PEO

IWS). Naval Sea Systems Command, Research & System

Engineering, Warfare Systems Engineering, and Human

System Integration Directorate (NAVSEA 05H).

2.3 NON-GOVERNMENT DOCUMENTS

ANSI/EIA-632

Processes for Engineering a System

ANSI/EIA-649-B

17 Jun 2011

Configuration Management Standard

ANSI/EIA-748-B

June 2007

Earned Value Management Systems

ANSI/EIA-STD-0007

August 2007

Logistics Product Data, Version 1.0

GEIA-STD-0007

15 October 2008

Logistics Product Data

IEEE 1633-2008 Recommended Practice on Software Reliability

IEEE/EIA 12207

Industry Implementation of International Standard ISO/IEC

IEEE/EIA 12207.0

Software Life Cycle Processes

IEEE/EIA 12207.1

Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.2

Software Life Cycle Processes - Implementation

Considerations

3.0 REQUIREMENTS

The work required by this Section 3.0 of the Statement of Work is applicable to all requirements under this contract.

In performing this work, the Contractor shall possess a SECRET security clearance level for access to classified information. This contract requires work with SSN 21 and SSN 774 Class submarines stealth performance data that falls under the protection of Alternative Compensatory Control Measures (ACCMs). Access to SSN 774 data is only authorized with specific prior permission from PMS450. Access to SSN 21 and SSN 22 data is only authorized with specific prior permission from PMS392, while SSN 23 requires specific prior permission from both

PMS392 and PMS394. Additional handling requirements in accordance with NAVSEA INSTRUCTION S5510.18

“SECURITY POLICY FOR STEALTH PERFORMANCE DATA WITH ALTERNATIVE COMPENSATORY

CONTROL MEASURES (ACCMS)" apply. The data under this protection will not be stored or processed within

Contractor's facility without additional PMS392, PMS394 and PMS450 approval, as applicable, and modifications to the DD254. In addition to possessing SECRET security clearance, personnel accessing classified information in the performance of this contract shall also possess ACCM.

3.1 GENERAL REQUIREMENT

The work required by this Section 3.1 of the Statement of Work (SOW) is applicable to software development and engineering services requirements.

3.1.1 Program Management

The Contractor shall designate a Program Manager who shall have responsibility for all aspects of this contract and the authority to commit the Contractor to specific courses of action. The Contractor shall perform all administrative, technical, and financial management functions required to support this effort and shall maintain the status, including all technical activities, problems or deficiencies, and recommended solutions. The Contractor shall be responsible for those activities assigned to subcontractors, to ensure the delivery of all supplies and services specified in this contract. [ELIN A001, DI-MGMT-80227]

3.1.1.1 Contract Work Breakdown Structure (CWBS)

The Contractor shall develop and maintain the CWBS and CWBS dictionary using MIL-STD-881C for guidance. The Contractor shall use the CWBS as the primary framework for contract planning, budgeting, and reporting of the cost, schedule and technical performance status to the Government. The Contractor shall analyze the system requirements specified in the SOW and system specification and translate them into a structure representing the products and services that comprise the entire work effort under the contract. The Contractor, if necessary, shall update the CWBS during the execution of the contract. Changes to the CWBS or associated definitions, at any reporting level, require Government approval. [ELIN A002, DI-MGMT-81334D]

3.1.1.2 Integrated Program Management Report (IPMR)

The Contractor shall apply Earned Value Management (EVM) principles and create and maintain an IPMR.

The Contractor shall report progress on all technical performance, cost, schedule, and data delivery requirements for engineering services and logistics for the common LWLCCA and LCCA Software. The Contractor shall provide access to all pertinent records, data and plans, as requested by the Government or their representatives. Integrated

Master Schedule (IMS) activities shall be reported in the IPMR. [ELIN A003, DI-MGMT-81861]

The Contractor shall conduct an Integrated Baseline Review (IBR) within six months of award to assess the

Contractor’s Performance Measurement Baseline (PMB). [ELIN A004, DI-ADMN-81249A], [ELIN A005, DI-

ADMN-81250A] The Contractor shall conduct an IBR for any major change to the contract, as determined by the

Contracting Officer’s Representative (COR). As part of the EVM requirements for this contract, the Contractor shall generate the Contract Funds Status Report (CFSR). [ELIN A006, DI-MGMT-81468]

3.1.1.3 Subcontract Management and Control

The Contractor shall identify and monitor subcontractor technical, quality, schedule, and milestone achievement on a continuing basis, according to the Contractor’s own established subcontract management techniques.

3.1.1.4 Program Risk Analysis

The Contractor shall identify significant program issues and raise them to the Program Office so that they can be monitored and resolved. The Contractor shall perform a continual analysis of program, technical, performance, cost, and schedule risks. The analysis shall identify the risks associated with each area, identify the impact of each risk on the overall program, and propose approaches for reducing identified risks. Risk analysis status shall be reported in the Contractor’s Progress, Status and Management Report and presented during Program

Reviews. [ELIN A001, DI-MGMT-80227]

3.1.1.5 Program Management Reviews

On a quarterly basis, the Contractor shall host a one-day Program Management Review (PMR) or participate in the PMS4012 Assistant Program Manager (APM) Review. [ELIN A004, DI-ADMN-81249A], [ELIN

A005, DI-ADMN-81250A]

The Contractor shall host the PMR at the Contractor’s facility or via Contractor-hosted video teleconferencing (VTC). The APM Review will be held in Washington, DC area. Technical issues will be discussed in terms of performance goals, exit criteria, schedule progress, and cost impact. At each review, the Contractor shall, at a minimum, report the status of the following:

a. cost/schedule performance

b. technical issues

c. software engineering

d. risk analysis and mitigation activities

e. reliability and maintainability

f. test and integration activities, plans, results

g. development activities -- completed and planned

h. logistics development and support efforts

i. safety program requirements

j. quality program

k. configuration management activities

l. Government-Furnished Property (GFP) and Government-Furnished Information (GFI) status

m. Integration readiness

n. efforts authorized under technical instructions

o. manpower utilization (actual) for preceding three-month period

p. manpower utilization (projection) for next nine months

q. data-deliverable schedule and status

r. hazardous material management efforts

s. status of action items from previous reviews

3.1.1.6 Technical Reviews

The Contractor shall host a one-day orientation meeting within 30 calendar days after initial contract award for Technology Insertion 2018 (TI-18). The Contractor shall host an additional meeting for TI-20 and this meeting will be defined in the Integrated Master Schedule (IMS) or contractor defined Program Plan. The orientation meeting will ensure that all requirements are clearly and mutually understood. Orientation meeting shall be held at the Contractor’s facility.

Technical reviews shall be held at the Contractor’s facility to discuss and evaluate software development status. Technical reviews shall be conducted on a periodic basis to determine progress and resolve issues. The structure and intervals will be defined in the Integrated Master Schedule (IMS) or contractor defined Program Plan.

The Contractor shall demonstrate how completion of required accomplishments associated with the event or milestone will be achieved for these reviews. As scheduled in the IMS, the Contractor shall conduct the following reviews each for TI-18 and TI-20 using ANSI/EIA-632 and/or PEO IWS / NAVSEA Technical Review Manual

(TRM) as guidance.

a. System Requirements Review (SRR) / System Design Review (SDR). The Contractor shall present its interpretation/understanding of the System Performance Specification requirements.

b. System Functional Review (SFR)/Preliminary Design Review (PDR). The Contractor shall present its system, software designs to show compliance with the system functional and performance requirements contained in the NAVSEA Technical Instructions. The completion of the SFR shall result in the establishment of the system software functional (performance) baseline.

c. Software Specification Review (SSR). The Contractor shall present system performance elements defined for all Computer Software Configuration Items (CSCIs). The completion of the SSR shall result in the establishment of a system software performance Allocated Baseline.

d. Subsequent reviews including the Critical Design Review (CDR) and Integration Readiness Review

(IRR), are to be held in accordance with the Contractor’s software development process and will be agreed to by the Navy at the conclusion of the SSR.

e. A Test Readiness Review (TRR) shall be completed a minimum of two (2) weeks prior to each test via a meeting between the Joint Test Group (JTG) Chairman, or his designated representative, and the

Contractor.

For each review, the Contractor shall generate and provide design review information package to the

Program Office. [ELIN A007, DI-SESS-81757A]

For each review, the Contractor shall transcribe meeting minutes and include action items assigned. [ELIN

A004, DI-ADMN-81249A], [ELIN A005, DI-ADMN-81250A]

3.1.1.7 Integrated Product Team (IPT)

The objective of the IPT concept is to assemble all stakeholders with a particular problem or issue who will expand the principal of concurrent engineering, utilizing a systematic approach to make team decisions based on timely input from the entire team, including customers and suppliers, and third party developers. The desired expectation is to move away from a pattern of hierarchical decision-making to a process where decisions are made across organizational structures by IPTs. These IPTs will integrate cost, schedule and performance data to provide a global perspective with detailed insight into the managerial and technical aspects impacting Government and industry.

IPTs are generally made up of representatives from the Government, the Contractor, subcontractors, vendors, and other industry partners and are chaired by the Government or Government representative. The

Contractor (including subcontractors and vendors as necessary) shall attend, present as necessary, and participate in

IPT meetings. During the Government fiscal year, a minimum of 12 and a maximum of 26 IPT meetings shall be held at either the Contractor’s facility or via the Contractor-hosted telephone conference.

As part of the IPTs, the Contractor shall have responsibility for the following functions:

a. Monitoring and reporting of Subsystem status and progress;

b. Joint identification, evaluation, management, and reporting of risk mitigation and cost reduction initiative efforts;

c. Identification, collection, analysis, and reporting of appropriate metrics for measurement of cost/schedule control, engineering;

d. Joint evaluation and management resolution of major issues associated with software engineering, software integration, and test activities;

e. Verification that the Contractor’s ‘early and often’ design disclosure process is providing data that is current, complete and accurate to third party developers;

f. Joint evaluation and management of the ILS effort; and

g. Joint recommended approval of data items requiring approval under this contract.

3.1.1.8 Coordination

The Contractor has responsibility for the LWLCCA and LCCA performance. Accordingly, the Contractor shall:

a. Participate in meetings (including coordination thereof) for efforts relating to the LWLCCA and

LCCA system.

b. Attend other contractor’s technical reviews and invite outside activities to its reviews when appropriate.

c. Provide, receive, and/or analyze information for others, which relates to the LWLCCA and LCCA system.

3.1.1.9 Data Management

The Contractor shall manage the development and use of data under this contract so as to afford the

Government visibility of all data.

The Contractor shall maintain Contract Data Status for recording, planning, scheduling, and reporting the status of program data requirements including electronic mail transmittals; and maintain a list of all contractor and subcontractor data generated in support of this contract. Data management shall adhere to the Team Submarine

Information Security Policy provided as Government Furnished Information (GFI).

3.1.1.9.1 Digital Data Management

All data shall be developed, managed, used, and delivered/exchanged electronically to the greatest extent practical. Communication via electronic mail (E-Mail) shall not relieve the Contractor of the responsibility to meet the contract requirements or change the contract requirements until a contract modification is issued by the

Contracting Officer.

3.1.1.9.2 Internal Data / Data Access

The Contractor shall establish and maintain E-Mail capability, compatible with NAVSEA PMS401

(transmit and receive). A list of files transmitted and/or to be transmitted electronically, along with any procedures necessary for accessing them, shall be included in the Contractor’s Progress, Status and Management Reports.

[ELIN A001, DI-MGMT-80227]

The Contractor shall provide program related data to the Government upon request. Data stored electronically shall be made available to the Government via practical electronic means (e.g. Internet, remote dial-in, local login, etc.). When hard copy delivery is necessary, the Contractor shall deliver data no later than (NLT) 15 calendar days following the written request. The Contractor shall identify accessible data.

3.1.1.10 Government Furnished Information (GFI)

GFI, identified in Attachment 2, shall be managed in accordance with DFARS 252.227-7025. Email verification of the receipt of GFI shall be provided per the Contract Data Requirement List (CDRLs) and specified distribution lists. GFI related issues (e.g., substandard quality, tardy submission) that have or may have an adverse effect on the performance will be referred to the COR for resolution. [ELIN A008, DI-MGMT-80596]

3.1.1.11 Government Furnished Property/Equipment/Material (GFP/E/M)

GFP/E/M, identified in Attachment 3, shall be managed in accordance with FAR 52.245-2. Email verification of the receipt of GFP/E/M shall be provided per the Contract Data Requirement Lists (CDRLs) and specified distribution lists. GFP/E/M related issues (e.g., substandard quality, tardy submission) that have or may have an adverse effect on the performance will be referred to the COR for resolution. [ELIN A009, DI-QCIC-

80736]

3.1.2 Systems Engineering

3.1.2.1 Systems Engineering Management

In compliance with ANSI/EIA-632, the Contractor shall establish an engineering process to support the tasks listed in this SOW. The engineering process must balance performance, risk, cost, and schedule. Further, it shall employ iterative processes for requirement analysis, functional analysis and allocation, design synthesis and verification, and system analysis and control. [ELIN A00A, DI-SESS-81785]

The engineering process shall ensure:

a. The compatibility, interoperability and integration of all functional and physical interfaces

b. That system definition and design reflect the requirements for software, facilities, people, and data

c. Technical risks are identified and managed.

3.1.2.2 Open Systems Architecture Approach

The Government intends to procure system(s) having an Open System Architecture and corresponding components. As part of this contract, the Contractor shall define, document, and follow an open systems approach for using modular design, standards-based interfaces, and widely-supported consensus-based standards. The

Contractor shall demonstrate compliance with open systems architecture during all technical reviews.

As part of an open system architecture approach, the Contractor shall identify to the Government all

Commercial-Off-the-Shelf/Non-Developmental Item (COTS/NDI) components, their functionality and proposed use in the system, and provide copies of license agreements related to the use of these components for Government approval prior to use.

In satisfying the Government’s requirements, the following system architecture approach characteristics shall be utilized:

a. Open Architecture - The Contractor shall develop and maintain an architecture that incorporates appropriate considerations for re-configurability, portability, maintainability, technology insertion, vendor independence, reusability, scalability, interoperability, upgradeability, and long-term supportability.

b. Modular, Open Design – The Contractor shall develop an architecture that is layered and modular and uses COTS/NDI products and technology, operating systems, and middleware that utilize non-proprietary or non-vendor-unique, key Application Programming Interfaces (APIs). The Contractor’s design approach shall be applied to all subsystems and components. The Contractor shall provide the

Government (and/or Government support contractors) electronic access to its integrated development environment throughout the term of the contract.

c. Modular Open Systems Approach (MOSA) –The Contractor’s design approach shall produce a system that consists of hierarchical collections of hardware configuration items (components). These components shall be of a size that supports competitive acquisition as well as reuse. The Contractor’s design approach shall emphasize the selection of components that are available commercially or within the Department of Defense (DOD), to avoid the need to redevelop products that already exist and that can be re-used.

As part of technical reviews (refer to Paragraph 3.1.1.6), the Contractor shall, at a minimum:

a. Describe how the proposed system software architecture meets the modular, open design goals, including the steps taken to use non-proprietary or non-vendor unique COTS or reusable NDI components wherever practicable.

b. Describe its rationale for the modularization choices made to generate the design.

c. Provide rationale that explicitly address any tradeoffs performed, particularly those that compromise the modular and open nature of the system.

d. Provide rationale for maintaining continued access to cutting edge technologies and products from multiple suppliers.

e. Describe how it will mitigate the risks associated with technology obsolescence.

f. Describe how it will avoid being locked into proprietary or vendor-unique technology and reliance on a single source of supply over the life of the system.

3.1.2.3 Specification Requirement Verification Matrix (SRVM)

The Contractor shall develop the SRVM to ensure traceability between the test requirements and the performance specification. [ELIN A00B, DI-MISC-81283]

3.1.2.4 System Engineering and Design Analyses

The Contractor shall develop System/Subsystem Design Descriptions (SSDDs) [ELIN A00C, DI-IPSC-

81432A NOT 1] in accordance with ANSI/EIA-632. In addition, the requirements outlined in Section 3.1.2.5

(Design Analysis) shall be included in the SSDD.

3.1.2.5 Design Analysis

The Contractor shall conduct detailed system engineering and design analyses of the proposed software system. The design analysis shall consist of detailed examinations of the software design techniques and software materials that the Contractor plans to use to meet the requirements of the specifications. The design analysis shall be specific on the system level. The design analyses shall evaluate the system concept in terms of operability, reliability, maintainability, and supportability objectives using MIL-STD-1472G, MIL-HDBK-470A, and / or IEEE-

1633-2008 as guidance. The Contractor shall examine the design details and modify them, as necessary, to ensure that the system design requires and/or utilizes the minimum amount of personnel and training requirements as practical consistent with the requirements of the specifications.

3.1.2.5.1 Failure Modes, Effects, and Criticality Analyses (FMECA)

The Contractor shall perform FMECA. The FMECA shall include all potential software failures. Results of

FMECAs shall be documented in the Failure Modes and Effects Analysis (FMEA) Report. [ELIN A00D, DI-SESS-

80980A]

3.1.2.5.2 Failure Reporting Analysis and Corrective Action System (FRACAS)

The Contractor shall analyze software failure data, addressing: historical operating time and data;

determination of the cause of each failure; components that have had more than one failure; planned corrective actions; and implementation and results of corrective actions including resultant reliability. The Contractor shall analyze the root cause for all pattern failures (more than one) and shall submit a failed item report (Failure Analysis and Corrective Action Report (FACAR)) for Government approval. If corrective actions are required, the Contractor shall prepare the FACAR report. [ELIN A00E, DI-SESS-81315B] If deemed necessary by the Government, the

Government will examine at the Contractor’s facility, the data from all failure and corrective action analyses.

The Contractor shall be responsible for correcting deficiencies discovered during the reliability test and for incorporating engineering change orders into the production baseline accordingly. Throughout the Test, Analyze and

Fix, and FRACAS processes the Contractor shall plot failure data on a Reliability Growth Curve to assess system reliability. The Contractor may recommend additional specific testing to assess unique system characteristics.

3.1.2.6 Information Assurance (IA)

The Contractor shall work with the Navy IA lead to ensure the LWLCCA and LCCA program is compliant with the DOD and Navy IA requirements. If required, the Contractor shall support the Government’s system security certification and accreditation.

3.1.2.7 Test and Evaluation Program Plan (TEPP)

The Contractor shall develop, maintain and update a Test and Evaluation Program Plan (TEPP) to describe all testing planned for and to define the process of integration of the LWLCCA and LCCA Software. The TEPP shall also address recent advances in Automated Test tools and techniques that can be accommodated during integration, build check out, and certification testing. [ELIN A00F, DI-NDTI-81284], [ELIN A00G, DI-NDTI-

80603A]

3.1.2.8 Integrated Logistics Support (ILS)

The Contractor shall establish an ILS program in support of the LWLCCA and LCCA system and deployment. The Contractor shall generate and deliver source logistics package, in a consistent, common format.

The Contractor shall designate an ILS manager to serve as the point of contact on ILS matters as well as participate in the various IPTs. [ELIN A00H, DI-ILSS-80095]

3.1.2.8.1 Supportability Analysis

The Contractor shall conduct Supportability Analysis as an integral part of the systems engineering process to ensure that supportability is a primary concern in system design and to demonstrate that the LWLCCA and LCCA

Software is cost effectively supportable. [ELIN A00D, DI-SESS-80980A] These analyses shall be performed using

MIL-HDBK-502A and GEIA-STD-0007, as guidance. At a minimum, the analyses shall include Failure Mode

Effects and Criticality Analysis (FMECA) and Reliability Centered Maintenance Analysis as follows:

a. Functional Requirements Identification with appropriate feedback to the design process;

b. Testability and Diagnostic Procedure Development;

e. Identification of Unique Support and Test Equipment (S&TE);

3.1.2.8.2 Interactive Electronic Technical Manual (IETM)

The Contractor shall develop technical manual S1000D Source Data Modules that integrate into the Prime

System Integrator developed AN/BQQ-10(V) IETM that documents the LWLCCA and LCCA capability. The Data

Modules shall provide a software overview, software configuration, safety, and emergency shutdown procedure that will aid in troubleshooting and restoring the software. [ELIN A00J, DI-TMSS-81814A], [ELIN A00K, Technical

Manual Contract Requirement No. NDMS-100001-000]

3.1.2.9 Configuration Management and Documentation

3.1.2.9.1 Software Baseline Identification

The Baseline Configuration Items (CI) software shall be documented in the configuration item/software functional specification.

3.1.2.9.2 Configuration Control

The Contractor shall manage configuration changes in accordance with the contract and ANSI/EIA-649-B.

The government approved product baseline and end items shall be changed only as a result of approved engineering change documentation.

3.1.2.9.3 Configuration Audits

The Contractor shall establish a configuration audit and review program that will ensure that the functional characteristics meet the requirements of the LWLCCA and LCCA In-Board Processing Specification.

The Contractor shall host and support the Government’s Functional Configuration Audit (FCA) to establish the software product baseline. [ELIN A00L, DI-SESS-81022D] The FCA verifies that the system is in compliance with the LWLCCA and LCCA In-Board Processing Specification. Satisfactory completion of all format and government witnessed testing as reflected in the approved SRVM and submission of the government signed test summary data sheets with the test report shall satisfy FCA requirements.

The Contractor shall develop a Configuration Audit Plan detailing all activities required to perform configuration audits for the items under this contract. Preparation of the plan shall be closely coordinated with the

Government. It shall include, but not be limited to, the following:

a. Schedules (time and place) of all audits;

b. Persons participating (Contractor and Government) and extent of participation;

c. Identification of the configuration items to be audited;

d. Description and extent of the audit to be performed;

e. Description of Contractor’s audit support such as but not limited to personnel, equipment, facilities;

A moratorium shall be imposed on all changes while the audit is conducted.

All changes in the process of being incorporated into the software and documentation shall be presented to the Configuration Audit Teams as the list of outstanding changes.

3.1.2.9.4 Configuration Status Accounting

The Contractor shall develop and maintain procedures that track the status of changes from the baseline, effectiveness, and status of implementation of Government approved changes. Data elements and related features used shall comply with ANSI/EIA-649. [ELIN A00M, DI-SESS-81253B]

3.1.2.10 Problem Reporting System

The Contractor shall establish a single system for the identification, tracking, and resolution of all software and baseline documentation problems identified during system development, and integration and testing. In addition, the system shall be used to track test documentation problems and technical manual errors. Status on problems shall be reported to the IPTs, Program Reviews, and Technical Reviews. All problems covered in this system shall be included with the Contractor’s Progress, Status and Management Report. [ELIN A001, DI-MGMT-

80227]

3.1.2.11 Engineering Change Documentation

3.1.2.11.1 Engineering Change Proposal (ECP)

The Contractor shall prepare and submit Class I ECPs to the Government for approval or disapproval as required. Proposed changes that would affect the form, fit, or Government controlled baseline, shall be implemented only after a Class I ECP is approved and authorized by the Procuring Contracting Officer (PCO) via a contract modification. [ELIN A00N, DI-SESS-80639D]

The Contractor is responsible for the development of ECPs and for all aspects of the implementation of the

ECP which are required to correct deficiencies. Implementation shall include, yet not be limited to, retrofit of all configuration items and provision of support resources called for under the contract to reflect any changes to be accomplished by the ECP to the extent necessary to allow all configuration items provided under this contract to be operated and maintained with the same support resources, such as operation and maintenance manuals, provisioning technical documentation, and maintenance repair parts for such items.

3.1.2.11.2 Class II ECPs, Minor RFVs

Proposed changes that would not affect form, fit, or function of a configuration item identified in a

Government controlled baseline, shall be submitted to the COR as Class II ECPs and minor RFVs for concurrence in classification only. [ELIN A00N, DI-SESS-80639D], [ELIN A00P, DI-SESS-80640D]

If the COR does not notify the Contractor otherwise within fifteen (15) calendar days after submittal, concurrence may be assumed. Class II changes that receive such concurrence will be implemented by the

Contractor. In addition, the Contractor shall update and provide source data for these changes.

In the event of non-concurrence, the Contractor shall stop further implementation of the proposed Class II

ECP or minor RFV at no increase in the price of this contract. The Contractor may resubmit the ECP as a Class I

ECP or major RFV or request review by the PCO within five (5) calendar days following the COR non-concurrence.

3.1.2.11.3 Request for Variance (RFV)

The Contractor shall prepare RFVs for the LWLCCA and LCCA items for Government review and approval as required. Authorized RFVs shall apply to a specific quantity of items for manufacture and will not permanently change the established baseline. Submittal of recurring RFVs is discouraged. [ELIN A00P, DI-SESS-

80640D]

3.1.2.11.4 Revision to ECPs/RFVs

The Contractor shall make revisions to ECPs/RFVs as needed.

3.1.2.11.5 Classified Data

When practical, ECPs or RFVs shall not be classified. Classified data essential to the evaluation and disposition of an ECP/RFV must be submitted separately in accordance with the security procedures established in the contract and referenced in the unclassified portion of the ECP.

3.1.2.11.6 Requests for Waivers

The Contractor shall prepare Requests for Waivers (RFWs) for the LWLCCA and LCCA items for

Government review and approval as required. Authorized RFWs shall apply to a specific quantity of items for manufacture and will not permanently change the established baseline. Submittal of recurring RFWs is discouraged.

[ELIN A00Q, DI-SESS-81732]

3.1.2.11.7 Specification Change Notices (SCNs)

The Contractor shall prepare a proposed SCN concurrent with a Class I ECP for each specification, if a revision is required upon approval of the ECP. The SCN shall be used to describe where and how the specification change will be made and provide instructions for pen and ink changes for minor changes or provide replacement specification pages. [ELIN A00R, DI-SESS-80643D]

3.1.2.11.8 Notice of Revision (NOR)

After ECP approval, the NOR shall be forwarded to the custodian of each specification, drawing, associated list, or other applicable document(s) so they can make the required documentation changes. [ELIN A00S, DI-SESS-80642D]

3.1.2.11.9 Engineering Change Instruction

The Contractor shall provide engineering support for the preparation of Government-generated engineering change instruction documents necessary to retrofit approved Class I Engineering Changes into delivered kits.

3.1.2.12 Quality Assurance (QA)

The Contractor shall establish, implement, and maintain a QA program that meets program objectives during the performance of the contract. The QA program shall, at a minimum, include the following four activities:

1. Monitoring and control of critical processes and product variation;

2. Establishment of mechanisms for feedback of field product performance;

3. Implementation of an effective root cause analysis and corrective action system; and

4. Continuous process improvement.

The Contractor shall provide status of ongoing quality assurance activities as part of the scheduled Program

Reviews and shall assist and support quality audits as may be requested by the Government.

The QA requirements shall be equally applicable to the Contractor’s subcontractors and suppliers. The

Contractor shall qualify and monitor vendor sources in conjunction with QA requirements and material procurements.

All quality assurance operations performed by the Contractor shall be subject to Government verification at any time, to include observing Contractor operations to determine that practices, methods and procedures of this contract are being properly applied.

3.1.2.13 Studies / Analyses

The Contractor shall conduct studies and analyses to meet the requirements and document the results of special studies and analyses as tasked. [ELIN A00T, DI-MISC-80508B]

3.1.2.14 Technical Data Package (TDP)

The Contractor shall develop Technical Data Package (TDP) each for TI-18 and TI-20 using MIL-STD-

31000A as guidance. The following products, at a minimum, shall be included in the TDP.

a. System/Subsystem Design Description (SSDD); [ELIN A00C, DI-IPSC-81432A NOT 1]

b. Interface Design Description (IDD); [ELIN A00U, DI-IPSC-81436A NOT 1]

c. Interface Requirement Specification (IRS); [ELIN A00V, DI-IPSC-81434A NOT 1]

d. Software Requirement Specification (SRS); [ELIN A00W, DI-IPSC-81433A NOT 1]

e. Software Design Description (SDD); [ELIN A00X, DI-IPSC-81435A NOT 1]

f. Software Product Specification (SPS) [ELIN A00Y, DI-IPSC-81441A NOT 1]

g. Software Version Description (SVD); [ELIN A00Z, DI-IPSC-81442A NOT 1]

3.2 SOFTWARE DEVELOPMENT

3.2.1 Software Engineering

The Contractor shall design, develop, test, and deliver common LWLCCA and LCCA software in support of A-RCI TI-18 (and higher) and APB-17 (and higher) which shall meet the Navy’s objectives for a common and open system architecture through the use of parameterization and scalability within the software design. The

Contractor shall follow the build-test-build approach to mature the developed technology.

The Contractor shall provide software baseline configuration updates in accordance with the IMS. The

Contractor shall define a software development approach appropriate for the computer software effort to be performed under this contract. This approach shall be documented in a Software Development Plan (SDP). The

Contractor shall follow this SDP for all computer software to be developed or maintained under this contract.

[ELIN A010, DI-IPSC-81427A NOT 1]

The SDP shall define the Contractor's life cycle model and the processes used as a part of that model. 'Life cycle model’ is defined in IEEE/EIA 12207.0. The SDP shall describe the overall life cycle and shall include primary, supporting, and organizational processes based on the work content of this contract. In accordance with the framework defined in IEEE/EIA 12207.0, the SDP shall define the processes, the activities to be performed as a part of the processes, the tasks which support the activities, and the techniques and tools to be used to perform the tasks.

IEEE/EIA 12207 does not prescribe how to accomplish the task, the Contractor shall provide this detailed information so the Navy can assess whether the Contractor's approach is viable. The SDP shall contain the information defined by Section 5.2.1 (generic content) and the Plans or Procedures in Table 1 of IEEE/EIA

12207.1. In all cases, the level of detail shall be sufficient to define all software development processes, activities, and tasks to be conducted. Information provided shall include, at minimum, specific standards, methods, tools, actions, strategies, and responsibilities associated with development and qualification.

3.2.1.1 Software Design Requirements

The Contractor shall provide software engineering services to meet the requirements of the contract. The

Contractor shall develop, code, and test software necessary to meet the requirements specified in the LWLCCA and

LCCA In-Board processing specification. The Contractor shall manage, update, and deliver computer software

(executable code and source code) in accordance with the SDP. [ELIN A010, DI-IPSC-81427A NOT 1]

The Contractor shall develop, update, and maintain Software Requirement Specification (SRS) [ELIN

A00W, DI-IPSC-81433A NOT 1], Software Design Description (SDD) [ELIN A00X, DI-IPSC-81435A NOT 1], and Software Product Specification (SPS) [ELIN A00Y, DI-IPSC-81441A NOT 1].

3.2.1.2 Interface Management and Documentation

The Contractor shall support system integration at the Prime System Integrator facility to ensure the common LWLCCA and LCCA software can functionally interface with the A-RCI Sonar System. This shall include, at a minimum, development of an Interface Requirements Specification (IRS) [ELIN A00V, DI-IPSC-

81434A NOT 1] and an Interface Design Description (IDD) [ELIN A00U, DI-IPSC-81436A NOT 1] between the

LWLCCA/LCCA system and A-RCI Sonar System. Each SRS shall describe the flow and algorithmic computations necessary to accomplish the functional string. The Contractor shall consider each function as a standalone entity. All of the processing for a function shall be considered as a whole (rather than as divisible entities to be combined later) in both the SRSs and the software. The level of detail in each IDD shall include, at a minimum, voltage/optical parameters, commercially applicable standards or formats, interface data, interface data formats, interface control and handshaking parameters, and interface frame, clock, and data rates. Each IDD shall provide this level of detail for communication and control from both sides of the interface.

To ensure traceability and completeness of interface requirements, references to requirements shall be included in the Specification Requirements Verification Matrix (SRVM). [ELIN A00B, DI-MISC-81283]

3.2.1.3 Software Version Description (SVD)

The Contractor shall provide a SVD for each common LWLCCA and LCCA software version delivered.

[ELIN A00Z, DI-IPSC-81442A NOT 1]

3.2.2 Integration and Test Engineering

The Contractor shall perform test to meet the requirements of the contract and achieve the specification performance. The contractor shall support integration activities with the AN/BQQ-10 System Integrator in accordance with NUWC-NPT Technical Memo 14-059. The Contractor shall implement and maintain a Test and

Evaluation Program. [ELIN A00F, DI-NDTI-81284]

The Contractor shall provide access to the system and test facilities for the Government to perform on-site independent tests, inspections, or evaluations.

3.2.3 Quality Assurance Testing

The Contractor shall utilize NUWC-NPT Technical Memo 14-003 Rev G as a guidance to conduct testing to verify quality assurance at the Contractor’s facility unless otherwise specified in Government approved test plans.

The testing shall, at a minimum, consist of the following tests.

Design Verification Test (DVT)

Software Operability Test

Performance Verification Test (PVT)

Software Reliability Demonstration

The Contractor shall generate a single test report. [ELIN A011, DI-NDTI-80809B NOT 1]

At IPT meetings and/or technical reviews, the Contractor shall report testing progress to date and projections for near-term activities. The Contractor shall include test activities and any significant problems affecting test progress. The contractor shall support integration and test with the AN/BQQ-10 System Integrator and aid in resolving problem trouble reports associated with the LWLCCA and LCCA Software, located at the integrator’s facility, Naval Shipyard and New Construction facilities, and at-sea onboard US submarines.

3.3 ENGINEERING SERVICES

Engineering services will be issued in accordance with the Special Contract Requirement entitled

“TECHNICAL INSTRUCTIONS” as directed by the COR or the Contracting Officer. The Contractor shall be required to provide necessary security clearances and visitor documentation to gain access to the installation yards and other industry partners’ facilities. The Contractor shall provide qualified engineer to:

a. Perform engineering services tasks related to LWLCCA and LCCA system. These services shall include but are not limited to modification, integration and checkout, test and evaluation, training, repairs, installation, inspection, technical issues resolution, trade studies, engineering change development, documentation, and logistics analyses.

b. Identify and incorporate software enhancements using emerging technologies, when feasible.