N00024-17-R-5216_Navy_ECDIS_RFP_Amendment_2.pdf

N0002415NR46120

AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT

Except as provided herein, all terms and conditions of the document referenced in Item 9A or 10A, as heretofore changed, remains unchanged and in full force and effect.

15A. NAME AND TITLE OF SIGNER (Type or print)

30-105-04EXCEPTION TO SF 30

APPROVED BY OIRM 11-84

STANDARD FORM 30 (Rev. 10-83) Prescribed by GSA

FAR (48 CFR) 53.243

The purpose of this amendment is to revise the follow ing:

1.) The proposal due date has changed from 8/29/2017 to 9/12/2017.

2.) Section C, SOW 3.3, 4.1.4, 4.1.6.1 3.) Section J, Attachment 11, Cost and Price Evaluation submittal sheet Rev. 2.

4.) Delete DFARS 252.234-7003 5.) Section L, L.4.2 Subfactor 2, L.4.3., L.4.4.

6.) Section M, M.2.1

1. CONTRACT ID CODE PAGE OF PAGES

S 1 59

16A. NAME AND TITLE OF CONTRACTING OFFICER (Type or print)

16C. DATE SIGNED

BY 10-Aug-2017

16B. UNITED STATES OF AMERICA15C. DATE SIGNED15B. CONTRACTOR/OFFEROR

(Signature of Contracting Officer)(Signature of person authorized to sign)

8. NAME AND ADDRESS OF CONTRACTOR (No., Street, County, State and Zip Code) X N00024-17-R-5216

X 9B. DATED (SEE ITEM 11)

15-Jun-2017

10B. DATED (SEE ITEM 13)

9A. AMENDMENT OF SOLICITATION NO.

11. THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS

X The above numbered solicitation is amended as set forth in Item 14. The hour and date specified for receipt of Offer X is extended, is not extended.

Offer must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended by one of the following methods:

(a) By completing Items 8 and 15, and returning 1 copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted;

or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN

REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified.

12. ACCOUNTING AND APPROPRIATION DATA (If required)

13. THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACTS/ORDERS.

IT MODIFIES THE CONTRACT/ORDER NO. AS DESCRIBED IN ITEM 14.

A. THIS CHANGE ORDER IS ISSUED PURSUANT TO: (Specify authority) THE CHANGES SET FORTH IN ITEM 14 ARE MADE IN THE

CONTRACT ORDER NO. IN ITEM 10A.

B. THE ABOVE NUMBERED CONTRACT/ORDER IS MODIFIED TO REFLECT THE ADMINISTRATIVE CHANGES (such as changes in paying office, appropriation date, etc.) SET FORTH IN ITEM 14, PURSUANT TO THE AUTHORITY OF FAR 43.103(B).

C. THIS SUPPLEMENTAL AGREEMENT IS ENTERED INTO PURSUANT TO AUTHORITY OF:

D. OTHER (Specify type of modification and authority)

E. IMPORTANT: Contractor is not, is required to sign this document and return copies to the issuing office.

14. DESCRIPTION OF AMENDMENT/MODIFICATION (Organized by UCF section headings, including solicitation/contract subject matter where feasible.)

10A. MOD. OF CONTRACT/ORDER NO.

2. AMENDMENT/MODIFICATION NO. 5. PROJECT NO.(If applicable)

6. ISSUED BY

3. EFFECTIVE DATE

10-Aug-2017

CODE

NAVAL SEA SYSTEMS COMMAND (HQ)

1333 ISAAC HULL AVE SE

WASHINGTON NAVY YARD DC 20376-2030

N00024 7. ADMINISTERED BY (If other than item 6)

4. REQUISITION/PURCHASE REQ. NO.

CODE

See Item 6

FACILITY CODECODE

EMAIL:TEL:

N00024-17-R-5216002

SECTION SF 30 BLOCK 14 CONTINUATION PAGE

SUMMARY OF CHANGES

SECTION A - SOLICITATION/CONTRACT FORM

The required response date/time has changed from 29-Aug-2017 02:00 PM to 12-Sep-2017 02:00 PM.

SECTION C - DESCRIPTIONS AND SPECIFICATIONS

The following have been modified:

STATEMENT OF WORK (SOW)

1.0 SOW Scope

This Statement of Work (SOW) addresses the Software Design Agent support required to produce, maintain, and upgrade the Navy Electronic Chart and Display Information System (ECDIS) Software (SW).

This SOW specifies the requirements for the production, integration, documentation, testing and delivery of the Navy ECDIS SW. The requirements in this SOW shall be applied to the initial Navy ECDIS SW Production Build (CLIN 0001) as well as the follow-on Maintenance Builds (CLINs 1001 and 2001), if options are exercised.

2.0 RESERVED

3.0 SOW Applicable Documents

3.1 Military Specifications, Standards, and Handbooks

MIL-STD-1472G Human Engineering dated 11 Jan 2012

3.2 Department of Defense (DoD) and Other Government Documents

Software Requirements Document (SRD) for the U.S. Navy Electronic Chart Display and Information System (NAVY ECDIS), Rev 1.0 (with Change 1), 13 JAN 2016 Requirements Traceability Matrix for the U.S. Navy Electronic Chart Display and Information System (NAVY ECDIS), Rev 1.0 (with Change 1), 13 JAN 2016 Configuration Management Plan for PEO IWS 6.0 Command and Control Directorate, Rev 4, 8 Sep 2014 NAVSEAINST 9410.2A, Naval Warfare Systems Certification Policy, 24 Aug 2012

OPNAVINST 9420.2A, Navy Electronic Chart Display and Information System Policy and Standards, 31 Oct 2014 PEO IWS / NAVSEA 05H Technical Review Manual, Version 2.0, 18 Dec 2009

DoD Open Systems Architecture, Contract Guidebook for Program Managers, v.1.1, Jun 2013

Electronic System Technical Manual for Navy Electronic Chart Display and Information System, Technical Manual Contract Requirement (TMCR) No. SNIPP-160030-000, 18 Dec DoDI 5200.39 Critical Program Information (CPI) Identification and Protection Within

Research, Development, Test and Evaluation (RDT&E), 28 May 2015

DoD Anti-Tamper (AT) Guidelines, Version 2.0 DoDI 8500.01, Cybersecurity, dated 14 March 2014 DoDI-8510.01 Risk Management Framework for DoD information Technology dated 12 March 2014

3.3 Non-Government Documents

ASTM F1166-07 Standard Practice for Human Engineering Design for Marine Systems, Equipment, and Facilities

IEEE 1044-2009 Standard Classification for Software Anomalies IEEE/EIA Std. 15289-2017 ISO/IEC/IEEE International Standard Systems and software engineering -- Content of life-cycle information items (documentation)

IEEE/EIA 12207-2008 Systems and software engineering -- Software life cycle processes NIST SP 800-64 Rev 2 National Institute of Standards and Technology (NIST) Security Considerations in the System Development Life Cycle NIST SP 800-53 Rev 4 NIST Security and Privacy Controls for Federal Information Systems and Organizations

Security Technical Implementation Guides (STIGs) Open Web Application Security Project (OWASP), Code Review Guide ISO 9001:2015 Quality Management Systems Requirements

3.4 Use of Standards

The Contractor shall use the following standards in descending order of importance:

a. Standards as specified in 3.1, 3.2 and 3.3.

b. Commercial standards developed by international or national industry standards bodies that have been widely adopted by industry. Examples of widely adopted standards include SQL for databases (e.g., SQL for databases ANSI ISO/IEC 9075-1, ISO/IEC 9075-2, ISO/IEC 9075-3, ISO/IEC 9075-4, ISO/IEC 9075- 5), HTML for presentation layer (e.g., XML 1.0 www.webstandards.org), XML for data transfer, Web services for remote system calls.

c. Standards adopted by industry consensus-based standard bodies and widely adopted in the market place.

d. De facto standards (those widely adopted and supported in the market place).

3.5 Contract Security Classification

The Contractor shall comply with Department Of Defense Contract Security Classification Specification, DD Form 254, attached hereto.

The Contractor is required to have an Active SECRET Facility Clearance for performance on this contract. The Contractor must have a Safeguarding Level of SECRET. The Government’s Program Manager will designate certain Contractor personnel required to have and maintain at a minimum a final SECRET security clearance.

The Contractor requires access to “For Official Use Only (FOUO)” which shall be managed in accordance with DoD M-5200.01 Volume 4, DoD Information Security Program: Controlled Unclassified Information (CUI) of 2/24/2012

The contractor requires access to classified source data up to and including SECRET in support of this contract.

Classified material generated in support of this contract shall be classified in accordance with the DD 254.

Automated Information Systems (AIS) must be certified and accredited by the Defense Security Services (DSS) prior to processing classified information.

The Contractor may be required to fabricate, modify, operate or store classified hardware, such as processor hard drives. All classified data and hardware will be protected in accordance with (IAW) DoD 5220.22-M, National Industrial Security Program Operation Manual (NISPOM) and DSS.

The Contractor, and any subcontractors or supplier, shall also comply with all requirements set forth in the DD-254.

The Contractor shall be solely responsible for obtaining any State Department approvals, licenses, Technical Assistance Agreements (TAA), etc. required by the International Traffic in Arms Regulations (ITAR). The Contractor shall submit all requests for State Department approvals, licenses, TAAs, etc. to the Program Office for review.

N00024-17-R-5216

4.0 SOW Requirement for Navy ECDIS SW, CLIN 0001

The Contractor shall produce Navy ECDIS SW in accordance with this SOW. The Navy ECDIS SW shall meet all requirements of the SRD for the U.S. Navy ECDIS. The following requirements apply to the initial Navy ECDIS SW Production Build 1.0 (CLIN 0001).

4.1 Software Development

The Contractor shall develop and implement secure coding and cyber security in accordance with NIST SP 800-64 Rev 2; NIST SP 800-53 Rev 4; the STIGs; DoDI 8500.01, Cybersecurity, dated 14 March 2014; DoDI-STD-

8510.01 Risk Management Framework for DoD information Technology dated 12 March 2014; and the Open Web Application Security Project (OWASP) Secure Coding Practices Reference Guide 2.0.

The Contractor shall develop and implement Anti-Tamper software protection measures, as appropriate, for the case of unplanned loss, to protect Critical Program Information (CPI) and Anti-Tamper Critical Technologies defined by DoDI 5200.39. DoD Anti-Tamper Guidelines, Version 2.0, is available as guidance. Anti-Tamper measures shall deter efforts to reverse engineer, exploit, or develop countermeasures. Anti-Tamper measures shall prevent unauthorized access to critical software functionality regardless of the system configuration.

4.1.1 Open System Architecture (OSA)

The Contractor shall produce the software with an OSA using modular design, standards-based interfaces, and widely-supported consensus-based standards in accordance with the SRD for Navy ECDIS SW paragraph 3.13.

The Contractor shall define, document, and follow an Open Systems Management Plan that incorporates appropriate considerations for re-configurability, portability, maintainability, technology insertion, vendor independence, reusability, scalability, interoperability, upgradeability, and long-term supportability.

CDRL A001 Management Plan, Open Systems Management Plan

4.1.2 Human Systems Integration (HSI)

The Contractor shall incorporate HSI principles and design during software design and integration activities in accordance with the SRD for Navy ECDIS SW. Periodic HSI Reviews will be held to allow user feedback into the Human Machine Interfaces (HMI). The Contractor shall develop a Human Systems Integration Program Plan (HSIPP) that describes their approach to develop and manage HSI requirements, elements, and functionalities to ensure the attainment of all HSI objectives. The Contractor shall incorporate the "Department of Defense Design Criteria Standard – Human Engineering" (from MIL-STD-1472G), into the HSI design of Navy ECDIS.

CDRL A002 Human Systems Integration Program Plan

4.1.3 Hardware Integration

The Navy ECDIS SW will be installed on all US Navy Commissioned Ships, Military Sealift Command vessels and Expeditionary platforms. The software will be installed at various shore commands in support of operational units.

This will require the software to operate on a wide variety of hardware configurations. SRD for Navy ECDIS SW Appendix A identifies platform configurations for many of the US Navy ships and Appendix J identifies the minimum expected hardware requirements that the software must operate on. The Contractor shall conduct testing IAW SOW 4.1.7.

The Contractor shall assess the system design defined by the SRD during initial production build, and if required, follow-on Maintenance Builds. The Contractor shall submit a Request for Variance (RFV) to propose any alternate design approaches and planned modifications to the system hardware for successful achievement of the SRD requirements in the event that hardware technology improvements are required to ensure performance of the system.

CDRL A006 Request For Variance (RFV)

4.1.4 Quality Assurance

The Contractor shall provide and maintain a quality management system in accordance with HQ-E-2-0015 QUALITY MANAGEMENT SYSTEM REQUIREMENTS (NAVSEA)(APR 2017) and shall adhere to the quality program controls of HQ-E-2-0014 QUALITY IN SOFTWARE DEVELOPMENT AND PRODUCTION (NAVSEA)(MAY1995). The Contractor shall submit a Quality Assurance Program Plan (QAPP) that documents all of the information, instructions and documentation necessary to produce quality software in complete conformity with contractual requirements. The QAPP shall address the software quality provisions of IEEE/EIA 12207.2008.

The QAPP shall contain measurable quality objectives and the metrics by which they are to be measured. The Navy ECDIS SW shall adhere to the approved QAPP. The QAPP shall be reviewed with each exercised contract option and, if required, revised and resubmitted.

CDRL A003 Quality Assurance Program Plan

4.1.5 Configuration Management (CM)

The Contractor shall prepare and submit a Software Configuration Management Plan. The CM Plan shall describe, at a minimum, the configuration management activities, procedures, and schedule for performing software CM activities; the organization(s) responsible for performing configuration management and activities; and their relationship with other organizations, such as software development and software maintenance. The Navy ECDIS SW shall adhere to the approved CM Plan. The CM Plan shall be reviewed, revised, and resubmitted as required.

A Software Configuration Control Board (SCCB) is to be established to control the software baseline. The SCCB shall be chaired by the Government (PEO IWS 6) and consist of both Contractor and Government representatives.

The SCCB shall discuss and review Software Problem Improvement Reports (SPIRs), review GFE/GFI deficiencies, review Request for Variance. The Government shall schedule the SCCB meeting as needed to address SPIRs. The SCCBs shall be via teleconference and scheduled within five working days of SPIR entry. The Government shall provide a list of SPIRs to be reviewed with each meeting notification.

The Contractor shall be responsible for maintaining the software configuration baseline over the life of this contract.

The Contractor shall use an industry standard distributed Software Configuration Management (SCM) system such as Git or Mercurial for all software production. The initial software baseline shall be established going into FQT, at which time the SCCB shall assume configuration control and no changes shall be implemented without SCCB approval.

The Contractor shall prepare and submit a GFI Deficiency/Change Report of the potential impact of deficient information provided under this contract. The Contractor shall prepare and submit a RFV to obtain authorization to deliver non-conforming material which does not meet the prescribed configuration documentation but is suitable for use or to depart from the contractually-specified configuration documentation for a specific period of time.

CDRL A004 Management Plan, Software Configuration Management Plan

CDRL A005 Government Furnished Information Deficiency Report

CDRL A006 Request For Variance (RFV)

4.1.5.1 Software Deficiency/Problem Corrections

The SCCB shall utilize the Naval Surface Warfare Center, Philadelphia Division (NSWC PD) Information Center Website SPIR database to document and manage all identified software discrepancies. Access to the SPIR database shall be granted to the Contractor for read access of the database. The Contractor shall be provided an editable excel file to forward and/or update SPIRs into the government database. The Contractor shall record all software discrepancies discovered during Contractor Formal Qualification Test (FQT) and provide SPIR file updates within five working days of discovery.

SPIRs can be detected in one of four methods, Analysis, Inspection, Demonstration and/or Test. All SPIR entries shall be reviewed by the SCCB before being entered into the SPIR database by NSWC PD. Data entered shall include: Severity, Priority, State, Analyst, Title, Issue Description, Related Trouble Report(s), Location, Comments/Action, and Status. SPIRs shall include problems interrelated between the Computer Software Configuration Items (CSCIs) and problems related to the overall software architecture. SPIR consequence shall be assessed against the likelihood of occurrence as per NAVSEAINST 9410.2A. SPIR Priority shall be assessed against Probability as per IEEE 1044. All implemented SPIRs must be tested to verify correction prior to software delivery

CDRL A007 Technical Report–Study/Services, SPIR Database Entry File

4.1.6 Software Data Products

The Contractor shall produce and provide data products as detailed in subparagraphs 4.1.6.1 – 4.1.6.9 in support of the Navy ECDIS SW. All rights shall be in accordance with DFARS 252.227-7014. The software data products previously submitted and approved shall be reviewed with each exercised contract option and, if required, revised and resubmitted in support of each Navy ECDIS SW Maintenance Build.

4.1.6.1 Software Development Plan (SDP)

The Contractor shall prepare and submit a Software Development Plan (SDP). The SDP shall define a software development approach appropriate for the computer software effort to be performed under this contract. The SDP shall be in compliance with Section C Clause HQ C-2-0065 Software Development Requirements (NAVSEA)(DEC 2006)(Modified)(SEP 2012), DoDI-STD-8500.01 Cyber Security, dated 14 March 2014 and DoDI-STD-8510.01 Risk Management Framework for DoD information Technology dated 12 March 2014. The Contractor shall follow this SDP for all computer software to be developed or maintained under this effort. The SDP shall be reviewed and updated, if required, with each Navy ECDIS SW Maintenance Build.

The SDP shall define the Contractor’s proposed life cycle model and the processes used as a part of that model. In this context, the term “life cycle model” is as defined in IEEE/EIA Std. 15289-2017 (system) and IEEE/EIA 12207- 2008 (software). The SDP shall describe the overall life cycle and shall include primary, supporting, and organizational processes based on the work content of this contract. 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. The Contractor shall provide this detailed information so the Government can assess whether the Contractor’s approach is viable. In all cases, the level of detail shall be sufficient to define all software development processes, activities, and tasks to be conducted. Information provided must include, at minimum, specific standards, methods, tools, actions, strategies, and responsibilities associated with development and qualification.

The SDP shall specify the entire software program and the performance characteristics of each CSCI. The Contractor shall update and attach to the SDP the SLOC Table provided as Attachment J-11 Worksheet 2h to the proposal. The SDP shall identify all third party software applications, and insure that the requirements of the application STIG are applied to such third party software application configuration required to by this plan, or submit a Request for Variance of non-conformance. For the purposes of this contract, any non-conformance of Application Security requirements as outlined per the STIGs is considered a variance from the CSCIs, but may be grouped together into a single Request for Variance for closely related STIG requirements relating to specific ECDIS functionality software requirements.

The Contractor shall allocate the Navy ECDIS performance requirements into the CSCIs listed in the SDP.

The Contractor shall be required to maintain the Navy ECDIS SW Requirements Traceability Matrix to further trace lower level software requirements and software testing beyond the SRD for Navy ECDIS SW. The Requirements Traceability Matrix shall be submitted concurrent with the submission of the lower level software requirements documents and software test documents; and in support of the SRR, SSR, PDR, CDR and TRR.

CDRL A008 Software Development Plan (SDP)

CDRL A009 Technical Report–Study/Services, Requirements Traceability Matrix

4.1.6.2 Software Requirements Specification (SRS)

The Contractor shall prepare and submit an SRS for each CSCI. The SRS shall be reviewed and updated, if required, with each Navy ECDIS SW Maintenance Build. The SRS shall specify the requirements for each CSCI and the methods to be used to ensure that each requirement has been met. Requirements pertaining to the CSCI’s external interfaces may be presented in the SRS or in one or more Interface Requirements Specifications (IRSs) referenced from the SRS. It has also been defined as a complete description of the behavior of the software to be developed. It includes a set of use cases that describe all of the interactions that the users shall have with the software. It also contains functional requirements, which define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing, and other specific functionality that shows how the use cases are to be satisfied. It also contains nonfunctional requirements, which impose constraints on the design or implementation (such as performance requirements, quality standards or design constraints). Each CSCI shall reference the SRS that it implements, and in each subunit shall call out the specific requirement from the SRS that it implements to insure requirement traceability.

CDRL A010 Software Requirements Specification (SRS)

4.1.6.3 Software Version Description (SVD)

The Contractor shall prepare and submit a SVD. The SVD shall be reviewed and updated, if required, with each Navy ECDIS SW Maintenance Build. The SVD shall identify and describe a software version consisting of one or more CSCIs. It is used to release, track, and control software versions. The SVD shall provide a summary of code changes, a listing of SPIRs corrected in the build, and a list of open deficiencies.

CDRL A011 Software Version Description (SVD)

4.1.6.4 Software Product Specification (SPS)

The Contractor shall prepare and submit an SPS. The SPS shall be reviewed and updated, if required, with each Navy ECDIS SW Maintenance Build . The SPS contains the executable software, source files, and software support information, including "as built" design information and compilation, build (to include information sufficient to reproduce the build environment), and modification procedures, for each CSCI. It is the detailed design and description of Software Items (SI) comprising the product baseline and is analogous to the Item Detail Specification of hardware Configuration Item (CI) in the product baseline of a hardware system. The source files, compilation and build files (such as a Makefile), etc., shall be delivered in the form of a complete SCM repository copy of the current build, with additional documentation in the SPS required as outlined above.

CDRL A012 Software Product Specification (SPS)

4.1.6.5 Software Design Description (SDD)

The Contractor shall prepare and submit an SDD. The SDD shall be reviewed and updated, if required, with each Navy ECDIS SW Maintenance Build. The SDD shall describe the design of a CSCI. It describes the CSCI- wide design decisions, the CSCI architectural design, and the detailed design needed to implement the software. The SDD shall include a description of software tools necessary to compile and produce an installable, executable copy of the Navy ECDIS SW on a DVD, including: identification of software compilers; a summary of code changes and at a minimum the difference files showing all changes from the baseline or a copy of the SCM for that CSCI at that baseline with the differences being spelled out clearly in the history of the SCM; a list of Windows Services used by Navy ECDIS; and software build procedures. The SDD may be supplemented by the Interface Design Descriptions (IDDs).

CDRL A013 Software Design Description (SDD)

4.1.6.6 Interface Requirements Specification (IRS)

The Contractor shall prepare and submit the IRS. The IRS shall be reviewed and updated, if required, with each Navy ECDIS SW Maintenance Build. The IRS shall specify the requirements imposed on one or more systems, subsystems, Hardware Configuration Items (HWCIs), CSCI, manual operations, or other system components to achieve one or more interfaces among these entities.

CDRL A014 Interface Requirements Specification (IRS)

4.1.6.7 Software Transition Plan (STrP)

The Contractor shall prepare and submit a STrP. The STrP shall be reviewed and updated, if required, with each Navy ECDIS SW Maintenance Build. The STrP shall identify the hardware, software, and other resources needed for the life cycle support of the Navy ECDIS SW and describe the Contractor’s plans for transitioning the software to NSWC Philadelphia Division (NSWC PD).

CDRL A015 Software Transition Plan (STrP)

4.1.6.8 Interface Design Description (IDD)

The Contractor shall prepare and submit the IDD. The IDD shall be reviewed and updated, if required, with each Navy ECDIS SW Maintenance Build. The IDD shall describe the interface characteristics of one or more systems, subsystems, HWCIs, CSCIs, manual operations, or other system components. The IDDs shall identify all external interfaces. The documentation shall include details for each message sent by each executable, broken down by word and data element. Each word and data element shall be fully described within the documentation. For interfaces defined by other systems and published in other documents, the IDD shall only reference the other documents.

CDRL A016 Interface Design Description (IDD)

4.1.6.9 Software Delivery

The Contractor shall provide the executables, source code, Application Program Interfaces (APIs), and development tools for any Contractor developed software scripts and software applications not developed exclusively or partially at private expense in accordance with DFARS 252-227-7017. In addition, the Government desires a Government Purpose Rights (GPR) license to all Contractor developed software. The Contractor shall deliver the software to the Government with the developmental elements necessary to allow the Government to generate an installable image or modify any element of the system. The delivery shall support the Government in generating a loadable image and configuring an existing system or a new (never before configured) system such that the system performs the same as the developmental system did during test. The Contractor shall provide assistance during this transition as needed for the Government team to successfully compile, build, load, configure, and operate a newly installed version.

The Contractor shall deliver the initial Navy ECDIS SW 1.0 Production Build once Contractor and Government testing is completed and the software is approved for Full Rate Production. Follow-on Maintenance Builds 1.1 and

1.2 shall be delivered with each exercised contract option once Contractor and Government testing is completed and the software is approved for Navy ECDIS use.

The Contractor shall ensure interoperability of commercial computer software with the OE and shall document any interdependencies (such as minimal revision required) in the appropriate Software Version Description(s) (SVD).

All licensing requirements/restrictions for each Commercial Off-The-Shelf (COTS) product shall be provided as part of the SVD. This documentation requirement shall include delivery of full paid software licenses which provide sufficient rights for the Government to meet and fulfill the needed and necessary Navy ECDIS SW capabilities over its lifecycle.

CDRL A017 Computer Software Product

4.1.7 Software Formal Qualification Test (FQT)

The Contractor shall establish and conduct a robust, comprehensive, and effective FQT program that provides proof the software is in compliance with the technical requirements of the Navy ECDIS SRD and the government approved SRS's and IDDs CDRLs delivered under this contract. The Contractor shall conduct FQT on all of the CSCIs managed under this contract. FQT shall include software unit testing, software integration testing and software system testing. The Contractor shall structure the FQT program to support not only the Contractor's in-plant software testing, but also support Government testing at Navy facilities. Contractor FQT is subject to monitoring by the Government. The Government must be notified a minimum of thirty (30) calendar days prior to any testing event and given the option to witness each event.

The Contractor shall utilize Navy ECDIS SRD compatible hardware for testing and acceptance of Navy ECDIS SW.

Shipboard representative hardware and peripherals for hardware compatibility testing, ECDIS qualified displays for backlight control and color palette testing and external interface testing will be made available at the In-Service Engineering Agent (ISEA) facility at NSWC PD (surface) and Naval Undersea Warfare Center (NUWC) Newport (submarine). NSWC PD has tools to simulate the following interfaces: synchro, ICD-150, serial and network NMEA, OD-17, OD-19, autopilot, RDS COMMS and analog Radar. NUWC Newport, RI has simulation capability for all SWFTS TI/APB interfaces to VMS. The Contractor shall perform the software FQT in accordance with the government approved Software Test Plan and Test Description. The Contractor shall document the FQT results via the Software Test Report. The STP, Software Test Description (STD) and Software Test Report (STR) shall be submitted for the initial Navy ECDIS SW 1.0 Production Build, as well as for each Navy ECDIS SW Maintenance Build.

Once the Contractor has successfully completed all FQT events, the Government shall perform formal Development Testing (DT) on the software at NUWC Newport, RI for submarine platform ECDIS configurations and at NSWC PD for surface platform ECDIS configurations. Once the Government Facilities DT is completed and all required SCCB identified SPIRs are corrected, Shipboard DT will be conducted in-port and underway on selected U.S. Navy platforms to further validate each software builds. Commander, Operational Test and Evaluation Force (COTF) will be conducting independent Operational Test (OT) of the software once the Government DT is successfully completed. The Contractor shall provide personnel to witness government testing at the labs and on the ships.

Personnel should have the required tools and documentation to be able to troubleshoot and document issues found for continuation of test events and to expedite SPIR resolution. For IMS purposes the Contractor should assume 90 days for the IWS Land-based DT which includes a 30 day period to correct priority SPIRs. The Contractor should assume 30 days for IWS At-Sea DT followed by 30 days for COTF OT.

As part of the Contractor’s FQT the software is to be tested by an independent agency such as the U.S. Naval Research Laboratory, Stennis Space Center (NRL, SSC) to ensure the software can properly display of National Geospatial-Intelligence Agency (NGA) data products. The Contractor shall provide, at minimum, a senior level software developer or test engineer to witness government testing. Personnel should have required tools and documentation to be able to troubleshoot and document issues found for continuation of test events and to expedite SPIR resolution.

Other Government testing that the Contractor will not be able to witness includes cybersecurity assessments of all source code and executable software applications to be installed on U.S. Navy Platforms. The Contractor is required to include their own cybersecurity assessment as part of the FQT to verify cybersecurity requirements in the SOW and SRD.

4.1.7.1 Software Test Plan (STP)

The Contractor shall prepare and submit the Software Test Plan (STP). The STP shall be reviewed and updated, as required, with each Navy ECDIS SW Maintenance Build. The STP shall describe plans for qualification testing of each CSCIs and software integration testing and software system testing. The plan shall describe the software test environment to be used for the testing, the configuration management plan for the test environment, an identification of risks for the testing planned, identification of the tests to be performed, testing criteria, prerequisites for the test event including hardware, databases, Operating System Settings, lab configuration diagrams, lab configuration validity check, best practices, image configuration, configuration file settings, regression testing strategy, and acceptance criteria; and provide schedules for test activities. The plan shall include unit cyber testing to include but not limited to input validation testing (“fuzz testing”), privilege escalation testing where privileged functions occur, and integrated unit functionality and conformance testing, integrated cyber security testing, and external penetration testing.

CDRL A018 Software Test Plan (STP)

4.1.7.2 Software Test Description (STD)

The Contractor shall prepare and submit the Software Test Description (STD). The STD describes the test preparations, test cases, and test procedures to be used to perform qualification testing of each CSCI or a software system or subsystem. The STD, test cases and test procedures shall be reviewed and updated, as required, in support of testing each maintenance software build.

CDRL A019 Software Test Description (STD)

CDRL A020 Test Procedures, Software Test Cases

4.1.7.3 Test Readiness Review (TRR)

The Contractor shall conduct a Test Readiness Review (TRR) no later than ninety (90) days prior to the scheduled start of the Contractor’s FQT for the initial SW 1.0 Production Build. The Contractor will coordinate with the Government to schedule the specific date. PEO IWS & NAVSEA 05H Technical Review Manual Appendix C shall be used in preparing the agenda and presentation material to satisfy the TRR entrance/exit criteria. The Contractor shall prepare and submit an agenda, presentation material and meeting minutes in accordance with CDRL A021, A022 and A023.

CDRL A021 Conference Agenda

CDRL A022 Presentation Material

CDRL A023 Report, Record of Meeting/Minutes

The objective of the TRR is to determine whether the software is mature enough to begin formal product (CI/subsystem/system) testing with an acceptable likelihood of successfully passing all Contractor and Government Formal Qualification Testing identified in paragraph 4.1.7.

The entrance criteria for the TRR are:

• Delivery of updated CDRL A009 Technical Report–Study/Services, Requirements Traceability Matrix

• Delivery of updated CDRL A027, Integrated Master Schedule (IMS) to reflect any changes from the PDR

• Delivery of CDRL A019 Software Test Description (STD)

• Delivery of CDRL A020 Test Procedures, Software Test Cases

• Risks identified, quantified, and reflected in the risk mitigation actions

• Controls and processes are in place to record and track software deficiency/problem corrections in accordance with paragraph 4.1.5.1

• Configuration Management controls and processes are in place to record and track software changes to the established baseline prior to the start of testing

The exit criteria for the TRR are:

• Delivered CDRLs reviewed and, where appropriate, approved.

• IMS captures all contractual major events, reflects the software development events necessary to complete each major event, identifies critical path and allotted time is judged to be reasonable

• Identified risks are agreed to, actions are acceptable in achieving required progress

• Software deficiency/problem correction processes are defined and acceptable

• Configuration Management controls are defined and acceptable

• All actions assigned at the TTR are approved

The Government shall provide written approval for the completion of the TRR once all exit criteria are met.

4.1.7.4 Software Test Report (STR)

The Contractor shall prepare and submit the Software Test Report (STR) for the initial SW 1.0 Production Build and for each exercised option for the SW Maintenance Builds. The STR is a record of the results of all qualification tests performed.

CDRL A024 Software Test Report (STR)

4.2 Program Management

The Contractor shall assign a Program Manager to be the primary government point of contact. The Contractor shall prepare and submit a Program Management Plan. The Program Management Plan shall identify the Contractor’s management efforts to ensure that all work conducted during this contract is planned and executed in a manner to meet the technical, cost, and schedule requirements of this contract. The plan shall also provide information on the contractor’s organization, practices, approaches and techniques to be used in managing the program as well as resources available.

CDRL A025, Program Management Plan

4.2.1 Monthly Status Reports

The Contractor shall submit a monthly Status Report that reflects the technical, schedule, and cost status of all work performed under the contract. The Status Report shall include but not be limited to, technical details related to software development parameters, work performed during the current reporting period and work planned for the next reporting period. Cost status shall include planned, actual, and cost to complete. The Contractor shall provide an Integrated Master Schedule (IMS). The IMS shall include all planned events and milestones, baseline, actual, and forecast dates. The IMS shall show internal dependencies, and relationships necessary to support accurate forecast of events and milestones dates, as well as the critical path. The report and IMS shall be used to support the monthly program and technical teleconference meetings.

CDRL A026, Contractor’s Progress, Status and Management Report

CDRL A027, Integrated Program Management Report (IPMR), Integrated Master Schedule (IMS)

4.2.2 Meetings and Reviews

The Contractor shall conduct the meetings and reviews as identified in the following subparagraphs for the base contract SW 1.0 Production Build and for each exercised option for the SW Maintenance Build. These meetings and reviews are to be held at the Contractor’s facility and are to be scheduled in the IMS. The Contractor shall prepare and submit Agendas for each meetings/reviews. Standard agendas shall be developed for reoccurring meetings/reviews. The Contractor shall prepare and submit presentation material that is to be presented at each meeting/review. The Contractor shall prepare and submit Meeting Minutes which document all material presented, key discussions and decisions made, and any action items which have arisen as a result of any meeting and review.

CDRL A021 Conference Agenda

CDRL A022 Presentation Material

CDRL A023 Report, Record of Meeting/Minutes

4.2.2.1 Program Meetings

The Contractor shall conduct and facilitate monthly teleconferences on the second Tuesday of each month. The monthly teleconference shall address work accomplished; work planned; progress as related to event-based schedule; cost; any programmatic challenges that the Contractor may be encountering as well as any identified by the Government and all open action items. The Contractor shall prepare and submit an agenda, presentation material and meeting minutes in accordance with CDRLs A021, A022 and A023.

4.2.2.2 Technical Meetings

The Contractor shall support technical meetings with the government on the second Wednesday of each month. The monthly teleconference shall address technical direction and progress; significant problems encountered; and assigned actions. The Contractor shall prepare and submit an agenda, presentation material and meeting minutes in accordance with CDRLs A021, A022 and A023.

4.2.2.3 Technical Reviews

The Contractor shall conduct and facilitate quarterly technical design reviews in support the Navy ECDIS SW program. The Contractor will coordinate with the Government to schedule the specific date. PEO IWS & NAVSEA 05H Technical Review Manual Appendix C shall be used in preparing the agenda and presentation material and establishing entrance/exit criteria.

4.2.2.3.1 System Requirements Review (SRR)

The Contractor shall conduct an SRR within 45 days after contract award. The Contractor will coordinate with the Government to schedule the specific date. PEO IWS & NAVSEA 05H Technical Review Manual Appendix C shall be used in preparing the agenda and presentation material to satisfy the SRR entrance/exit criteria. The Contractor shall prepare and submit an agenda, presentation material and meeting minutes in accordance with CDRL A021, A022 and A023. The objective of the SRR is to ensure that the Navy ECDIS Software Requirements Document (SRD) has been successfully implemented by the software architecture, that the software design has the potential of meeting the SRD when acceptably balanced with cost, schedule, and technical risk, and that the plans for moving ahead with software development are reasonable and of acceptable risk. A thorough review of the software architecture and development plans that will guide the software development process shall also be accomplished, and all lower level requirement reviews should show how they incorporate into this architecture and plan.

CDRL A021 Conference Agenda

The entrance criteria for the SRR are:

• Delivery of CDRL A001, Management Plan, Open Systems Management Plan

• Delivery of CDRL A002 Human Systems Integration Program Plan

• Delivery of CDRL A003 Quality Assurance Program Plan

• Delivery of CDRL A004 Management Plan, Software Configuration Management Plan

• Delivery of CDRL A008 Software Development Plan (SDP)

• Delivery of CDRL A009 Technical Report–Study/Services, Requirements Traceability Matrix

• Delivery of CDRL A025, Program Management Plan

• Delivery of CDRL A027, Integrated Program Management Report (IPMR), Integrated Master Schedule

(IMS)

• Risks identified, quantified, and reflected in the risk mitigation actions

• Software architecture is defined and requirements are allocated

The exit criteria for the SRR are:

• IMS captures all contractual major events, reflects the software development events necessary to complete each major event, identifies critical path and allotted time is judged to be reasonable

• Identified risks are agreed to, actions are acceptable in achieving required progress

• The software architecture and functionality is consistent with the requirements and judged adequate to proceed to SSR

• All assigned actions from the SRR are documented

The Government shall provide written approval for the completion of the SRR once all exit criteria are met.

4.2.2.3.2 Software Specification Review (SSR)

The Contractor shall conduct an SSR within 75 days after contract award. The Contractor will coordinate with the Government to schedule the specific date. PEO IWS & NAVSEA 05H Technical Review Manual Appendix C shall be used in preparing the agenda and presentation material to satisfy the SSR entrance/exit criteria. The Contractor shall prepare and submit an agenda, presentation material and meeting minutes in accordance with CDRL A021, A022 and A023. The objective of an SSR is to determine the state of the requirements for each of the software configuration items, and to assess whether these requirements are sufficiently mature to continue software development.

CDRL A021 Conference Agenda

The entrance criteria for the SSR are:

• Delivery of updated CDRL A009 Technical Report–Study/Services, Requirements Traceability Matrix to reflect SRD flow-down and allocation to the SRS, SDD, IRS, and IDD

• Delivery of CDRL A010 Software Requirements Specification (SRS)

• Delivery of CDRL A013 Software Design Description (SDD)

• Delivery of CDRL A014 Interface Requirements Specification (IRS)

• Delivery of CDRL A016 Interface Design Description (IDD)

• Delivery of CDRL A018 Software Test Plan (STP)

• Delivery of updated CDRL A027, Integrated Program Management Report (IPMR)Integrated Master Schedule (IMS)

• Risks identified, quantified, and reflected in the risk mitigation actions

• All software configuration items are defined and all requirement are allocated

• All assigned actions from the SRR are complete

The exit criteria for the SSR are:

• IMS captures all contractual major events, reflects the software development events necessary to complete each major event, identifies critical path and allotted time is judged to be reasonable

• Identified risks are agreed to, actions are acceptable in achieving required progress

• The software architecture and functionality is consistent with the requirements and judged adequate to proceed to PDR.

• All assigned actions from the SSR are documented

The Government shall provide written approval for the completion of the SSR once all exit criteria are met.

4.2.2.3.3 SW Preliminary Design Review (PDR)

The Contractor shall conduct a SW PDR within 180 days after contract award. The Contractor will coordinate with the Government to schedule the specific date. PEO IWS & NAVSEA 05H Technical Review Manual Appendix C shall be used in preparing the agenda and presentation material to satisfy the PDR entrance/exit criteria. The Contractor shall prepare and submit an agenda, presentation material and meeting minutes in accordance with CDRL A021, A022 and A023. The objective of the SW PDR is to review the architectural design of the software configuration items to verify its compliance to the requirements established during the SSR, the planned test approaches, and the overall progress being made in developing the configuration items, as it fits into the total system.

CDRL A021 Conference Agenda

The entrance criteria for the PDR are:

• Delivery of updated CDRL A009 Technical Report–Study/Services, Requirements Traceability Matrix to reflect any changes from the SSR

• Delivery of updated CDRL A027, Integrated Program Management Report (IPMR), Integrated Master Schedule (IMS) to reflect any changes from the SSR

• Risks identified, quantified, and reflected in the risk mitigation actions

• The architectural design defines the functions, performance, and interface requirements that will govern coding and testing of the CI.

• The detailed design of the CI and its relation to the allocated requirements and its role within the overall system is defined.

• All assigned actions from the SSR are complete

The exit criteria for the PDR are:

• IMS captures all contractual major events, reflects the software development events necessary to complete each major event, identifies critical path and allotted time is judged to be reasonable

• Identified risks are agreed to, actions are acceptable in achieving required progress

• The software architecture and configuration items are consistent with the requirements and judged adequate to proceed to CDR

• Software Configuration Items development processes/methods are appropriate and adequate to track process until the software is tested and delivered

• All actions assigned at the PDR are approved

The Government shall provide written approval for the completion of the PDR once all exit criteria are met.

4.2.2.3.4 SW Critical Design Review (CDR)

The Contractor shall conduct a SW CDR within 270 days after contract award. The Contractor will coordinate with the Government to schedule the specific date. PEO IWS & NAVSEA 05H Technical Review Manual Appendix C shall be used in preparing the agenda and presentation material to satisfy the SW CDR entrance/exit criteria. The Contractor shall prepare and submit an agenda, presentation material and meeting minutes in accordance with CDRL A021, A022 and A023. The objective of the SW CDR is to provide the opportunity to assess the completeness of the detailed design and how it supports the performance requirements as well as overall progress being made in developing the system.

The entrance criteria for the CDR are:

• Delivery of updated CDRL A009 Technical Report–Study/Services, Requirements Traceability Matrix to reflect any changes from the PDR

• Delivery of updated CDRL A027, Integrated Program Management Report (IPMR), Integrated Master Schedule (IMS) to reflect any changes from the PDR

• Risks identified, quantified, and reflected in the risk mitigation actions

• Software architecture objectives and requirements tradeoffs to meet performance have been assessed

• Software Configuration Items development processes/methods are defined and progress is being measured

• All assigned actions from the PDR are complete

The exit criteria for the CDR are:

• IMS captures all contractual major events, reflects the software development events necessary to complete each major event, identifies critical path and allotted time is judged to be reasonable

• Identified risks are agreed to, actions are acceptable in achieving required progress

• The software architecture and configuration items are consistent with the requirements and judged adequate to proceed

• Software Configuration Items development processes/methods are appropriate and adequate to track process until the software is tested and delivered

• All actions…