N00024-17-R-5216_Navy_ECDIS_RFP_Amendment_1.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/14/2017 to 8/29/2017.

2.) Section B, Note A and Note H.

3.) Section C, SOW 4.1.6, 4.1.6.9, 4.1.7, 5.0, 7.0, and 8.0.

4.) Delete Clause HQ C-2-0024, and include updates to Clauses HQ C-2-0065 and HQ E-2-0015.

5.) Incorporate 5252.216-9122 Alt I by full text.

6.) FAR 52.252-2

7.) CDRL, DD Form 1423, Exhibit “A”.

8.) Section J, Attachment 11, Cost and Price Evaluation submittal sheet.

9.) Section L, L.3.1, L.4.1, L.4.2, L.4.3.

10.) Section M, M.2, M.2.1, M.3.1, M.4

1. CONTRACT ID CODE PAGE OF PAGES

S 1 62

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

16C. DATE SIGNED

BY 02-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

02-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-5216

SECTION SF 30 BLOCK 14 CONTINUATION PAGE

SUMMARY OF CHANGES

SECTION A - SOLICITATION/CONTRACT FORM

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

SECTION B - SUPPLIES OR SERVICES AND PRICES

The following have been modified:

SECTION B NOTES

NOTE A - INCENTIVE FEE INSTRUCTIONS FOR CLIN 0001

Note: Upon award, the successful Offeror's proposed maximum and target fee percentages, if less than the solicitation stated thresholds, will be incorporated in the paragraph below and in FAR clause 52.216-10 INCENTIVE FEE in Section I.

Minimum fee shall be zero percent (0%). Maximum fee shall be eleven percent (11%). Target fee shall not be greater than nine (9%). Additionally, these fee maximums apply to all subcontractors when CPIF type subcontracts are proposed.

The share ratio for the CPIF portion of the fee structure is 50/50 (50% Government and 50% Contractor) for both under-runs and over-runs. The fee earned under the CPIF portion of the fee structure will be based on the total allowable cost incurred by the contractor in comparison to the final target cost for CLIN 0001. See the Incentive Fee clause (FAR 52.216-10) in Section I of this contract for further information on how the target cost and target fee are determined and the fee earned is calculated.

NOTE B - Applicable to CLINs 0002, 1001, and 2001 - These CLINs are Cost Plus Fixed Fee (CPFF). The Offeror shall propose no more than eight percent (8%) for fixed fee. The available fixed fee amount shall be calculated as a percentage of cost, less FCCM. The Government will issue Technical Instructions in accordance with NAVSEA 5252.242-9115 TECHNICAL INSTRUCTIONS (APR 2015) included in Section H of this contract. This is an estimated amount of labor hours, and does not indicate that the Government will necessarily require this amount or any at all.

CLIN Hours Section B Fixed Fee Amount

Section B Fixed Fee Amount/Hours

0002 5,682 * *

1001 28,408 * *

2001 28,408 * *

* Offerors shall complete this table. The Offeror shall divide the proposed Section B fixed fee amount by the associated hours and insert the result rounded to the nearest penny in the appropriate column in the table above. The Offeror shall propose no less than zero percent (0%) and no more than eight percent (8%) for fixed fee. The proposed Section B Fixed Fee Amount shall be in whole dollars. The Government reserves the right to unilaterally correct any mathematical errors.

NOTE C - Option item to which the option clause in SECTION I-2 applies and which is to be supplied only if and to the extent said option is exercised. Applicable CLINs: 0002, 0003, 1001, 1002, 1003, 2001, and 2002.

NOTE D - Applicable to CLINs 0003, 1002, and 2002 - Offeror is to propose the Government specified Estimated Cost only amount indicated in the table below.

CLIN Travel Material Total Estimated Cost

0003 $70,000 $0 $70,000 1002 $70,000 $0 $70,000 2002 $70,000 $0 $70,000

NOTE E - Applicable to CLINs 0002, 1001, and 2001 - Level of Effort Items in accordance with NAVSEA Provision 5252.216-9122 entitled “LEVEL OF EFFORT” to the contract. The hours shown in the schedule are the hours allocated for each CLIN to be performed within the period established under Section F of the contract entitled “DELIVERIES OF PERFORMANCE” and include both prime and subcontracts hours.

NOTE F- Applicable to CLINs 0002, 1001, and 2001 - The Government will issue Technical Instructions (TIs) in accordance with NAVSEA 5252.242-9115 TECHNICAL INSTRUCTIONS (APR 1999) included in Section H of this contract. The Contractor shall not perform any efforts under these items until and unless tasked by the Government. The Offeror is required to price man-hours per option year. This is an estimated amount of labor hours, and does not indicate that the Government will necessarily require this amount or any at all. These CLINs are Cost Plus Fixed Fee (CPFF). Any allowable Travel, Other Direct Costs (ODC) or Incidental Material associated with the performance of the TIs will be reimbursed with the associated Travel/ODC CLINs.

NOTE G - Applicable to CLIN 0004 (Data CLIN). The item is NOT SEPARATELY PRICED (NSP).

NOTE H – Applicable to CLIN 1003, Data Rights/ Licenses - The Offeror shall fill this in with their proposed price for those rights which the Offeror is willing to sell in accordance with Section L.4.1 paragraph (7) which states - the Government desires at least Government Purpose Rights (GPR), as defined at DFARS 252.227-7013 and - 7014, in all non-commercial technical data and computer software. Where less than GPR are being provided to the Government, the Government requests that the Offeror provide the price of buy-out for GPR or license fees for those rights which the Offeror is willing to sell. The Offeror shall not include the prices of the buy-out options in the Technical Approach, Volume II, of the proposal. Rather, for each technical data/computer software deliverable which is being offered with less than GPR, prices for conversion of the deliverable data rights to GPR or license fees shall be included in CLIN 1003.

SECTION C - DESCRIPTIONS AND SPECIFICATIONS

The following have been added by full text:

HQ C-2-0065 SOFTWARE DEVELOPMENT REQUIREMENTS (NAVSEA) (JUN 2017)

(a) The contractor shall define a general Software Development Plan (SDP) appropriate for the computer software effort to be performed under this contract. The SDP shall, at a minimum:

(1) 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 Std. 12207:2008;

(2) Contain the information defined by ISO/IEC/IEEE 15289:2017, section 7.3 (generic content) and the Mapping of ISO/IEC 12207:2008 (IEEE Std. 12207:2008) Clauses to Information Items for Each Software Life Cycle Process in Table 2 of ISO/IEC/IEEE 15289:2017. In all cases, the level of detail shall be sufficient to define all software development processes, activities, and tasks to be conducted;

(3) Identify the specific standards, methods, tools, actions, strategies, and responsibilities associated with development and qualification;

(4) Document all processes applicable to the system to be acquired, including the Primary, Supporting, and Organizational life cycle processes as defined by IEEE Std. 12207:2008 as appropriate. Such processes shall be equivalent to those articulated by CMMI®;

(5) Include the content defined by all information items listed in Table 2 of ISO/IEC/IEEE 15289:2017, as appropriate for the system and be consistent with the processes proposed by the developers;

(6) Adhere to the characteristics defined in section 6.1 ISO/IEC/IEEE 15289:2017, as appropriate;

(7) Describe the overall life cycle and include primary, supporting, and organizational processes based on the work content of this contract;

(8) Be in accordance with the framework defined in IEEE Std. 12207:2008, including, but not limited to, defining 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;

(9) Contain a level of information sufficient to allow the use of the SDP as the full guidance for the developers. In accordance with 7.3 of ISO/IEC/IEEE 15289:2017, such information shall at a minimum contain, specific standards, methods, tools, actions, reuse strategy, and responsibility associated with the development and qualification of all requirements, including safety and security.

(b) The SDP shall be delivered to the Government for concurrence under CDRL and shall not vary significantly from that proposed to the Government for evaluation for award. The contractor shall follow the Government concurred with SDP for all computer software to be developed or maintained under this effort. Any changes, modifications, additions or substitutions to the SDP also require prior Government concurrence.

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

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)(SEP2009) 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-2015 (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 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…