Attachment 1 - CTSO INC1 SOW - 27JAN22.docx

Close Terrain Shaping Obstacle (CTSO) Increment 1 (INC1) Common Anti-Vehicle Munition (CAVM) Based Top Attack (TA) System

Statement of Work

6 January 2022 27 January 2022

REVISIONS NOTED IN BLUE HIGHLIGHTS

Version 1.0

Contents

INTRODUCTION / BACKGROUND

The Army and Joint Forces require the capability to shape terrain with lethal obstacles across the battlespace. Lethal obstacles are a force multiplier that enable joint forces to fight outnumbered and win against near-peer enemies, while reducing friendly force casualties. Increment 1 (INC1) is the first of three increments which will progressively add to the Close Terrain Shaping Obstacle (CTSO) capability. The envisioned CTSO Increment 1 Common Anti-Vehicle Munition (CAVM) Based Top Attack (TA) system, hereafter also referred to as CTSO INC1, will support the CAVM based Abbreviated Capability Development Document (A-CDD). The CAVM based A-CDD calls for a munition design intended to leverage as much of the CTSO design as practical for future mid and deep systems. The design will provide a U.S. Landmine Policy compliant TA capability to address the Army’s directed close tactical obstacle capability gap as an enduring solution.

The CTSO INC1 system will include an anti-vehicle TA with human in the loop, on-off-on, obstacle control capabilities at safe standoff distances. The system will also employ modular open systems architectures, cyber, command, control, communications, and computer (C5) capabilities, and displays real-time, authoritative munition field safety information to the operator to enable a disarmed safe state (on-off-on).

. SCOPE / OBJECTIVE

The Government is seeking innovative solutions for the CTSO INC1 prototype system. The Contractor will have a limited timeframe to develop the prototype followed by system testing and production as described by the Milestone schedule. The prototype system shall be comprised of both Class V and Class VII components. This program seeks to leverage non-developmental items (NDI), commercial off the shelf (COTS), and novel solutions to improve the Government evolution of Terrain Shaping Obstacles (TSO).

A hand-emplaced TA anti-vehicle system will be developed. The munition design will serve as the basis for a common munition to be used in close, mid, and deep obstacles. The TA capability will be controlled by a remote control station (RCS). An obstacle planning capability will also be developed. The RCS will have the capability to import a plan generated by the obstacle planning capability to facilitate field emplacement. A solution is sought for authoritative data to be provided to the operator to control the system.

The Government is seeking affordable solutions that maximize operational capabilities while minimizing logistics footprints. Considerations should be given to survivability, reliability, maintainability, portability, and long-range communications of the system. Additional tasks include sending obstacle information to the Army command and control (C2) system. The Contractor shall design and implement system C2 processes that support the User with timely collection and accurate presentation of information in dynamic operational environments. Developed C2 information, decision, and execution management processes will enable the User to observe, orient, decide and act in a decisive manner in kinetic environments.

Additionally, it is expected the Contractor will develop a full task trainer, an exportable TA version, and a TA emplacement trainer in conjunction with the primary INC1 effort described within. Design solutions and prototypes shall include progress deliveries to the Government to support touch and knowledge points. Soldier Touch Points (STPs), as specified in this SOW, will evaluate the suitability of the concept and will direct which features to finalize at a minimum of every 12 months.

The Government seeks successful qualification and documentation in support of type classification and Full Materiel Release (FMR) as described in Army Regulation (AR) 770-3. To meet program milestones, the Contractor will complete design, modeling, and simulation (M&S), development, integration, product acceptance, manufacturing technology processes and equipment, and test. The Contractor shall design and build a prototype TA CAVM munition system to support a rapidly hand-emplaced TSO TA lethal munition system that, when combined with a bottom attack munitions, provides a complex obstacle capability against enemy targets and breaching vehicles.

Iterative Prototyping: This prototype project will allow for an iterative prototyping process. Under this iterative prototyping process, the Government may modify, by mutual agreement, this prototype project to allow the adaptation and modification of the technology being prototyped to meet additional unique and discrete purposes/mission sets.

Follow-On Production Contract or Transaction: In accordance with 10 U.S.C. 2371b(f), and upon a determination that the prototype project for this transaction has been successfully completed, this competitively awarded prototype OTA may result in the award of a follow-on production contract or transaction without the use of competitive procedures. If this project is successful, the Government anticipates awarding a follow-on contract or transaction to support production of an estimated 3,441 munitions. This number includes possible orders from foreign military sales (FMS) and other DoD entities.

This prototype project will be deemed successfully completed upon a written determination that the efforts conducted under this Agreement: (1) met the key technical goals of a project; (2) satisfied success metrics incorporated into the Prototype OTA; or (3) accomplished a particularly favorable or unexpected result that justifies the transition to production. Any concept/technology/solution successfully proven through this prototype OTA can be transitioned to production. Furthermore, successful completion can occur prior to the conclusion of the prototype project to allow the Government to transition any aspect of the prototype project determined to provide utility into production while other aspects of the prototype project have yet to be completed.

The Key Technical Goals for this prototype project are as follows:

1. This project will be deemed successful upon completion of the Government’s Safety Sequential Transportation Test flow (4.3.4). The Contractor will deliver a report documenting the outcome from the Government’s Safety Sequential Transportation Test (5.2.75).

2. After further iterative development and testing, currently scheduled to conclude at the end of Year 5, this project will be deemed successful upon completion and delivery of the Initial Operational Test and Evaluation (IOT&E) Test Readiness Report (5.2.86).

APPLICABLE DOCUMENTS

The document summary list (DSL), Appendix A, lists documents that are incorporated as part of the other transaction authority (OTA). Documents are listed in the DSL by number, title, and date. Document versions specified in the DSL take precedence over generic references (without revision letters) cited in the statement of work (SOW). If documents should conflict, the following order of precedence shall govern:

d. Test and Evaluation Strategy (TES) In the event that any document inconsistency affects contractual performance, the Contractor shall notify the Government immediately both verbally and in writing.

REQUIREMENTS

NOTE: All references to "days" in this SOW and the CDRLs listed in Appendix B, that are not specifically identified as "business days" or calendar days" shall be interpreted and understood as "calendar days".

The Requirements Section 4.0 is broken out into three basic groupings of system tasks; Increment 1 (INC1) (Tasks 1-3), Additional INC1 (Tasks 4 -6) and INC3 (Tasks 7-8). Task 1 describes all the required tasks for INC1, including the engineering support activities to support INC1. The tasks for Contractor System Verification Tests (Task 2) and Government System Verification Tests (Task 3) are tasks to support contractor and Government testing of the INC1 system. Task 4 Additional INC1 Attributes may be initiated by the Government at award based on funding allocated to Task 4 milestones but may not be completed if the Government decides not to fund additional Task 4 milestones. The Contractor shall include Task 4 attributes initiated by the Government in Contractor System Verification Tests (Task 2) and Government System Verification Tests (Task 3) as described in Task 5 and Task 6, respectively. The contractor shall provide only ROM pricing for tasks 7-8 in their PPON response since these tasks are optional. The Government may choose to initiate CTSO Increment 3 (INC3) requirements after award. If desired by the Government, the Agreements Officer (AO) will issue a request for a proposal for tasks 7 and 8 prior to completion of task 6. The Contractor is not authorized to start work or incur costs associated with Tasks 7 and 8 until authorized by the AO. If Task 7 and 8 are turned on by the AO, then the Contractor shall include the requirements for the attributes in Task 7 as part of the Contractor System Verification Tests as described in Task 2. The Contractor shall ensure a design approach that completes all other mandatory and resource tasks without schedule delay for Government discontinuation.

Task 1 Increment 1 (INC1) Requirements Technology Development Description The Contractor shall design, develop, and manufacture a prototype system that provides a C2 TA anti-vehicle lethal obstacle capability sufficient to shape terrain by disrupting enemy maneuver and defeating threat forces. The TA system shall be compliant with U.S. Landmine Policy issued by the Department of Defense (DoD). The Contractor’s design of the system shall meet systems requirements listed in the SRD. The Contractor’s design shall also provide a system that accommodates a Modular Open Systems Approach (MOSA) where feasible. In combination with MOSA, design considerations for technology obsolescence and technology refresh, the Contractor shall incorporate design elements and features to facilitate exportability of the INC1 with minimal impacts to both the U.S. only and exportable TSO INC1 configurations. During the design phase, the Contractor shall identify critical technologies, critical program information (CPI), and trusted systems and networks (TSN) components necessary to deliver and protect mission critical functionality of the INC1. The Contractor shall consider anti-tamper (AT) and differential capabilities (DC) as risk mitigation measures. The Contractor shall consult the FY21 Defense Exportability Findings Study as a guide to designing for exportability.

Top Attack (TA) Common Anti-Vehicle Munition (TA CAVM) Launch Module The Contractor shall design and build a prototype CAVM TA launch module that facilitates the hand emplacement of the TA system. The design shall contain integrated components to support the engagement of threat vehicles and the launch of the TA munition. Computer aided design (CAD) and engineering analysis performed by the Contractor shall confirm the module size, weight, power, and system performance are on-target with system requirement as outlined in the SRD.

TA CAVM

The Contractor shall design and build a prototype TA CAVM that meets the system requirement as outlined in the SRD. The CAD and engineering analysis performed by the Contractor shall confirm the TA CAVM size, weight, power, and performance are meeting system requirements.

TA CAVM for Middle Terrain Shaping Obstacles (MTSO) / Deep Terrain Shaping Obstacles (DTSO) The system shall maximize commonality as a modular mission payload with future delivery methods to include artillery, missile, rotary wing, and fixed wing aircraft in support of a long-term CAVM acquisition approach. The TA CAVM subcomponents should adhere to a form factor that allows for future integration into 155mm artillery and precision strike missile (PrSM) delivery to the maximum extent possible. The CAD and engineering analysis performed by the Contractor shall confirm the suitability of the TA CAVM for future delivery and shall be captured in the Preliminary Design Review (PDR) and Critical Design Review (CDR) deliverables and in a technical report (DI-MISC-80508B) fifteen days prior to PDR and updated fifteen days prior to CDR.

MTSO/DTSO Analysis The Contractor shall address any TA CAVM subcomponents that cannot be directly leveraged to support future 155mm and PrSM artillery delivery via analysis to outline a growth path to achieving the required form factor. The TA system subcomponents shall address survivability for 155mm and PrSM delivery to the extent possible and where not feasible to implement, shall address via analysis to indicate a design approach to achieving the required survivability and form factor. The analysis for a MTSO/DTSO delivery concept shall be presented and delivered at CDR in Contractor format technical report (DI-MISC-80508B).

Command, Control, and Computers (C3) The Contractor shall develop a prototype RCS that incorporates functions, control mechanisms, and interfaces required to control the TA system as described in the SRD. The Contractor shall define workflow mechanisms for controlling the TA system by collaborating with the Government community through workshops, STPs, or other synergistic stakeholder events designed to refine and develop intuitive C3 control architectures. Engineering and software analysis performed by the Contractor shall confirm performance is on-target with system requirement. The contractor shall support the Information Support Plan (ISP) development, written by the government team. The contractor will provide all systems dependencies and interface requirements in sufficient detail to enable testing and verification of Information Technology (IT) and National Security Systems (NSS) interoperability and supportability requirements. The contractor’s command and control architecture design shall be scalable to include the addition of components from future CTSO Increment 2 Bottom Attack and features of CTSO Increment 3 Full Network Capability.

Communications The Contractor shall select and integrate existing communication systems and/or radios that are either National Security Agency (NSA) certified or NIST FIPS 140 Level 2 approved, and which will support the C2 functions of the TA subsystems and the RCS as described in the SRD. The design shall consider Risk Management Framework (RMF) implications when applicable. The Contractor shall support coordination with the Army Spectrum Management Office and deliver DD 1494 (DI-MISC-81174) on all spectrum dependent equipment. The contractor’s communication architecture design shall be scalable to include the addition of components from future CTSO Increment 2 Bottom Attack and features of CTSO Increment 3 Full Network Capability.

Cyber-Security Plan The Contractor shall work with the Government to define and implement a cyber-security plan considering confidentiality, integrity, and availability of system data and communication links between TA systems in the field and RCS. The Contractor shall work with the Government to identify cyber requirements, characterize the attack surface, conduct vulnerability identification and analysis, and verify survivability and resilience in an operational context. The Contractor shall work with the Government to define security domains and cyber-security requirements for data-at-rest and data-in-transit. The Contractor shall define keying approach and document the approach in a key management plan (DI-MISC-81688) fifteen days before PDR and updated fifteen days before CDR. The Contractor shall support the program office in its coordination with NSA.

Authoritative Safety Information The Contractor shall design and implement a prototype to display safety critical information to the RCS operator according to system requirement. Contractor shall consider component obsolescence risks within the design and provide a solution capable of being incrementally acquired over the next ten (10) years. The contractor’s design shall be scalable to include the addition of components from future CTSO Increment 2 Bottom Attack.

Obstacle Planning The Contractor shall design and develop an obstacle planning prototype to assist the user with the creation of an obstacle plan in accordance with the SRD.

Software Engineering (SE) CTSO INC1 System Software The Contractor shall deliver all CTSO INC1 System software developed under this contract, including but not limited to the TA munitions and the munition launcher; RCS for C2 of munitions; the TSO obstacle-planning and management tool, and the authoritative safety information.

For purposes of this SOW, software shall be defined (but not limited to) as embedded computing system items called software, firmware, microcode, source code, object code, machine code, machine language, application software, operating system, programs, routines, symbolic languages, device drivers for hardware interfaces to all subsystems, interfaces for inputs and outputs to other systems to include systems simulated for testing, training, and maintenance, and algorithms, computer simulations, previously developed software, to include commercially developed software and related material that would enable the software to be reproduced, recreated or recompiled. The Contractor shall identify all COTS hardware and software used in development and tactical configurations including manufacturer, serial numbers, and versions (as applicable).

Software Transition Plan The Contractor shall provide hardware and software and assist the Government’s prototype set-up, test-case development, and troubleshooting activities of INC1 hardware and software provided under this Agreement. The Contractor shall document and post the configuration of their software development environment such that it can be replicated at a Government facility. The Contractor shall develop and deliver a Software Transition Plan (STrP) that is preliminarily submittal 180 days prior to end of the contract and finalized 60 days prior to the end of the contract (DI-IPSC-81429A).

Software Metrics The Contractor shall develop and follow a codified approach to collecting metrics in accordance with (IAW) the ISO/IEC TR 9126. Measurements and analysis shall be kept current and made available to the Government. The Contractor shall generate the following metrics: computer resources (memory and throughput usage), requirement count, source lines of code (SLOC), and defect tracking of baselined software artifacts. Measurements and analysis shall be kept current and made available to the Government upon request.

CTSO INC1 Software Design and Development The Contractor and all Sub-Contractors shall design, develop, integrate, and test all software for the CTSO INC1 using Standard for Information Technology – Software Life Cycle Processes (IEEE/EIA 12207.0). The Contractor shall establish and maintain continuous, bi-directional traceability of each CTSO INC1 computer software configuration item (CSCI) utilizing a requirement-tracing database such as DOORs. This requirement for continuous, bi-directional traceability includes traceability from system requirements to software requirements through software design description to software test description.

Support Software The Contractor shall deliver all developed non-tactical software used to support program development, maintenance, and testing of the CTSO INC1 system.

Software Peer Reviews The Contractor shall include Government representation in their internal software development peer reviews and Software Configuration Control Board (SCCB) for any changes after Formal Qualification Test (FQT).

System/Software Architecture Description Document The Contractor shall develop and maintain a System/Software Architectural Description Document of software architecture (DI-IPSC-81435A). The Contractor shall update and maintain a unified modeling language (UML)-based CTSO INC1 system architecture and software model. The use of UML shall follow guidelines of the object management group (OMG) UML version 2.4.1 specification or higher.

The System/Software Architecture Description Document shall include the following UML diagrams:

Structure Diagrams (e.g. Block Definition Diagrams) to identify the structural elements of the proposed solution.

Behavioral Diagrams (e.g. Use Case, State Machine, Activity, Sequence diagrams) that are capture the behavior, event timing, and message/communication of proposed solution. Behavioral elements shall be traceable to system and component level requirements.

Traceability Views (e.g. matrices, tables) to show traceability to System Requirements.

Diagrams or Views (e.g. Internal Block Diagrams, Tables, Matrices) to identify external and internal interfaces.

Draft of the System/Software Architectural Description Document shall be delivered 15 days prior to the PDR, delivered when major updates are added, and final delivery shall occur 30 days after final software release. Contractor developed architecture products will integrate/incorporate salient data from user developed operational architectures to effectively interoperate with systems and technical architecture schemas.

Software Development Plan (SDP) The Contractor shall develop, maintain, and deliver a software development plan (SDP) in accordance with DI-IPSC-81427A 60 days after agreement award and after major software changes. The Contractor shall develop new software or modify existing software IAW coding standards defined in the Contractor’s SDP. The Contractor shall identify all COTS hardware and software in the SDP. The Contractor shall employ an agile software development approach. The Contractor shall work closely with the Government in the design of CTSO INC1 to ensure meeting user needs. The Contractor shall designate a single Software Product Owner to provide oversight and direction of all project activities. The single point of contact (POC) Software Product Owner must have authority to make decisions and discuss emerging problems with the Government. The Contractor shall hold periodic standup, sprint planning, product backlog refinement, and sprint review meetings with Government personnel in attendance, based on availability. The Contractor shall annotate, refine, and prioritize the backlog consisting of features (e.g. User stories) that are maintained in toolsets agreed upon by the Government (e.g. GitLab, Altassian JIRA, etc.). The Contractor shall conduct release and sprint planning on the subset of technical requirements and high-level design elements to be satisfied during each sprint and subsequent release taking feedback from Government personnel. The Contractor shall capture and document the technical requirements and acceptance criteria for each sprint validated by the Government during sprint reviews. The Contractor shall follow a development process that allows for periodic Government prioritization of software features. Consistent with agile and sprint based development, the contractor shall incorporate features and requirements in an order approved by both the Contractor and Government, which may be subject to change based on sprint planning during the period of the contract.

In accordance with the Army’s Cloud Plan, the Army’s ability to master the application of cloud computing is a critical enabler in the pursuit to operationalize data. As such, the Contractor shall develop at least an identical mirror copy of the system’s software in a Government approved and provided cloud environment requiring Common Access Card (CAC) authentication for access control. The contractor shall utilize Government provided and Government Cloud Service Provider (CSP) platforms and services to develop the system when made available by the Government Enterprise Cloud Management Agency (ECMA). These platforms and services include modern source code repository, automated build, testing, static code analysis, software composition analysis, dynamic penetration testing, artifact storage, containerization, hosting, telemetry and monitoring tools. The Contractor shall use these provided tools to establish and execute continuous integration pipelines and software development processes that will be reviewed by the Government. If Government CSP platforms and services are not made available for use by the ECMA at the time of contract award, the government will provide guidance on when specific capabilities will be made available. The contractor will have the option to independently provision and use specific similar capabilities in advance of being provided by the ECMA to mitigate risk.

The Contractor must physically maintain all data solely on equipment located within the legal jurisdiction of the United States IAW DFARS 239.7602-2(b). All data, including but not limited to system technical documentation, administrative data, support data, and billing data, transmitted via the development environment shall reside at all times in data processing and storage equipment located in the United States or in data processing and storage equipment of which the operation and maintenance are subject only to the laws of the United States. Data transmitted must only be subject to disclosure pursuant to U.S. Federal law and not the laws of any other jurisdiction or foreign nation. All DoD information/data placed or created by DoD users in a Cloud Service Provider’s (CSP) Cloud Service Offering (CSO) is owned by the DoD, the Mission Owner, and/or their Information Owner. The CSP has no rights to the DoD’s information/data.

The Government shall furnish the root cloud accounts that shall house at least an identical mirror copy of the contractor software development environment, source code and artifact repositories, continuous integration tools, automated scanning and testing tools and their appropriate roles as Government Furnished Equipment (GFE) to the contractor to manage when made available by the ECMA. The Contractor shall ensure at all times that the Government has highest access rights to the root cloud account (e.g., if they change passwords, Government gets the new password).

Software Requirements Specification (SRS) and Interface Requirement Specification (IRS) The Contractor shall develop, deliver, and maintain a Software Requirements Specification (SRS) (DI-IPSC-81433A) including Interface Requirements Specification (IRS), DI-IPSC-81434A. An initial draft SRS/IRS is due as part of the SRR/SFR package. An updated draft SRS/IRS is due to the Government 15 days prior to the Software Requirements Review and PDR. A final SRS/IRS shall be delivered 30 days after the Critical Design Review (CDR).

Software Requirements Review (SwRR) The Contractor shall conduct a Software Requirements Review (SwRR) to enable the government to assess readiness to enter the design phase. The first SwRR shall be conducted no later than 90 days after SRR. A SwRR will then be conducted for each software block. The Contractor shall verify that each software, interface, and safety requirement are traceable to the CTSO INC1 system specifications and subsystem specifications. The Contractor shall provide a method of verification for each requirement that is jointly agreed upon with the appropriate Government Integrated Product Team (IPT) lead.

Software Design Review (SDR) The Contractor shall conduct a Software Design Review (SDR) at PDR to allow the Government to assess readiness to enter the coding phase. This review will assess the software design and architecture as captured in the software design description (SDD), Architectural Description Document, and Interface Design Description (IDD) and address considerations of software safety, maintainability, portability, modularity, and reusability. The contractor shall ensure that each function in the functional baseline has been allocated to one more software requirements. The contractor shall present an updated program schedule highlighting software critical path drivers, and whether the Integrated Product Team is prepared to start formal coding and development of test procedures. The contractor shall tailor the review with respect to technical scope and system risk. The SDR shall take place at the contractor's facility. The contractor shall conduct a readiness review two weeks prior to SDR, during which the readiness of the program to conduct a successful SDR will be assessed

Software Design and Test Description The Contractor shall design, develop, integrate, and test all software for the CTSO system using Contractor software development processes tailored for the CTSO and defined as part of the Technical IPT. The Contractor shall establish and maintain continuous, bi-directional traceability of each CSCI. This includes traceability from system requirements to software requirements through software design description to software test description. The Contractor shall deliver an SDD DI-IPSC-81435A and a Software Test Description (STD). The initial draft SDD is due 15 days prior to the PDR and the final SDD is due 30 days after final software release.

Interface Design Description (IDD) The Contractor shall develop and deliver an IDD (DI-IPSC-81436A initial draft SDD 15 days prior to the PDR and the final SDD is due 30 days after final software release.

Software Test Plan The Contractor shall develop and deliver to the Government a software test plan (DI-IPSC-81438A) delivered 30 days after SRR/SFR, and further submissions shall be sixty (60) working days before any FQT and safety certification testing. The software test plan shall describe the plan for qualification testing of CSCIs and software systems against the software requirements. The software test plan shall describe the test environment to be used for testing, identify the required resources, identify tests to be performed, and provide schedules for test activities.

Software Test Description (STD) The Contractor shall develop and deliver to the Government an STD to verify requirements (DI-IPSC-81438A). The Contractor shall deliver the STD 30 days prior to any FQT and safety certification testing.

The Contractor shall develop and make available documentation, test procedures, routines, data, and test results to the Government in the agreed upon Contractor’s external repository within a week of FQT completion. All tests shall identify any safety critical characteristics of a requirement and specify the testing of these characteristics. For each safety critical component, testing shall comply with the processes described in AOP-52 and as appropriate per Test and Evaluation (T&E), Software, and Safety IPTs. The Contractor shall deliver a data collection plan, including updated revisions containing defects and test data sets from the demonstration, to the Government. The data shall include all message traffic sent and received, and safety critical data. The Contractor shall tailor and utilize the data in support of the verification and validation of CTSO INC1.

Software Test Routines and Data The contractor shall develop and make available to the Government in Windchill software test procedures, routines, data, and test results. This data shall include:

a. All tests shall identify any Safety Critical characteristics of a requirement specifying how these characteristics are being properly tested. For each Safety Critical component, testing shall comply with the processes described in AOP-52 as appropriate per the T&E, software and Safety IPT for the EMD phase.

b. The Contractor shall establish and execute a software acceptance test IAW the SDP, STP and STD. For each software item, the Contractor shall conduct a Test Readiness Review (TRR) before beginning testing. Government shall have access to witness any software test event to include: unit level testing, code reviews, integration testing, safety testing, and dry-run testing.

c. A data collection plan, including updated revisions containing defects and test data sets from the demonstration shall be delivered to the Government. This data shall include: 1) All message traffic sent and received, and 2) Safety critical data. This data will be tailored and utilized to support the Verification and Validation of CTSO Inc 1.

d. The contractor shall track and prioritizing all software change requests (SCR), Defects, and Problem Change Request (PCR), resulting from reviews, analysis, and testing which will be provided to the Government upon request.

Formal Qualification Test (FQT) The Contractor shall conduct a Formal Qualification Test (FQT) dry run and FQT Record Test, as defined as part of the T&E IPT and in accordance with the SDP, software test plan, and STD. The FQT shall be conducted at the Contractor facility and test results shall be included in the Software Test Report (4.1.2.21). The Contractor shall perform software FQT IAW SDP, software test plan, SRS, and STD at the CSCIs and system level. FQT testing shall be conducted at least two (2) months prior to CDR. The Contractor shall conduct a Software TRR before beginning testing. The Contractor’s TRR shall be approved by the Government prior to execution of testing. The Government shall have access to witness any software test event to include unit level testing, regression, code reviews, integration testing, safety testing, dry-run testing, and FQT.

The Contractor shall conduct testing of the baseline software release and for each software item conduct a FQT, TRR, and Full Record FQT (FFQT).

Software Version Description (SVD) The Contractor shall develop, deliver, and maintain an SVD (DI-IPSC-81442A). The Contractor shall deliver an initial draft of the SVD 10 days prior to FQT with a final due 30 days following the last formal software release.

Software Review, User Test, and Evaluation The Contractor shall employ Agile software development methodology for this effort. The CTSO INC1 development shall be conducted in sprints initiating after the PDR or after SDR. During each sprint, the Contractor shall collaborate closely with the Government to iteratively test and evaluate the CTSO INC1 software throughout the development cycle. Continuous Integration (CI) and automated test artifacts including test plans shall be provided to the Government in advance of testing and in accordance with Software Test Plan (DI-IPSC-81438A) and Software Test Report (DI-IPSC-81440A). At the conclusion of each sprint, the Contractor shall provide associated test reports and a demonstration of the system to the Government. Government feedback and recommended modifications from sprint reviews shall be documented by the Contractor to inform further development in future sprints. Any proposed modifications to previously delivered software releases provided to the Government during the development lifecycle shall be coordinated with the Contractor. The Contractor shall host these demonstrations virtually at a specified time and date agreed upon by the CTSO Contracting Officer Representative (COR)/PM, CTSO program analyst, task manager, and Contractor. Software releases resulting from completion of sprints leading up to, including, and improving upon the Minimum Viable Product (MVP) shall be made available for Government end-users to evaluate against their mission requirements can be used to influence future development sprints. The Contractor shall review and analyze all test results and associated data and fix, resolve, and overcome any problems or conditions found which prevent the software from performing the capabilities and functions listed in this SOW. The modifications shall be completed and incorporated into the CTSO INC1 software before final delivery.

Software Test Reports (STRs) The Contractor shall develop and deliver an STR (DI-IPSC-81440A) to the Government and shall be delivered 30 days after software test events and fourteen (14) days after FQT events. The STR shall enable the Government to assess the testing and its results against the software requirements or equivalent. The Contractor shall track and prioritizing all software change requests (SCR), defects, and problem change request (PCR) resulting from reviews, analysis, and testing. The Contractor shall provide these requests to the Government either digitally via e-mail or through an agreed to external repository.

Software Delivery The Contractor shall develop and deliver a Software Product Specification (SPS) and the software (source code and documentation) to the Government per each software version (DI-IPSC-81441A, tailored). Initial SPS shall be delivered for the release following successful FQT. Subsequent deliveries shall follow any updated software releases. The SPS shall include any Contractor software control drawings to include any artifacts produced by or associated with compilation/build, test, and deployment procedures.

Software Maintenance The Contractor shall design and implement a software upgrade port within the DLM to support future software upgrades (only accessible for depot level maintenance). All software tools, procedures, documentation, and diagnostic equipment necessary to perform testing and upgrades of software (including Government use rights) shall be included in the System Support Package.

The Contractor shall ensure that the system accepts authorized system updates through the maintenance port. The Contractor shall provide a system that prevents software and firmware from modifications during runtime. The system is required to apply appropriate vulnerability management including patch management to mitigate known threats and effects of obsolescence prior to deployment.

Final Delivery At the time of delivery, the Contractor shall deliver all software needed to operate the system, including compilers, software architecture, and a complete version of any source code with unlimited rights, examples, and instructions for developing, building, and compiling the software components (including COTS listing for development environments and settings). The final delivery shall be installed on Government sustainment lab equipment including a development lab prototype CTSO hardware set up and include all software, tools, and licenses required to reproduce the developed software. In conjunction with final delivery, the Contractor shall conduct a training session of the CTSO INC1 software at a mutually selected location. A virtual training session may be permitted pending Agreement Officer Representative (AOR) approval. During this session, the Contractor shall provide instruction on operation of the CTSO INC1 RCS, its features, capabilities, and any significant specifications of the software. The Contractor shall deliver one electronic copy of the user manual at final delivery.

Software Quality Assurance (SWA) Static Code Analysis The Contractor shall provide technical support in terms of codebase, compilation environment for multiple iterations of static code analysis conducted by the Government through automated testing, secured file transfer, teleconferencing, and remote desktop sharing. The Contractor shall enforce secure coding practices to mitigate defects determined by the Government.

Software Coding Practices The Contractor shall enforce secure coding practices to remove potential software vulnerabilities by conducting the following activities:

Implement software assurance process for development, including configuration control, tools, and automation per SDP.

Perform code inspection and analysis using secure coding rules and guidelines, tools, processes, and methods as agreed upon in the Technical IPT.

Implementing recommendations from automated testing tool scan results Software Assurance Testing The Contractor shall enforce software assurance testing by completing the following activities:

Perform non-functional testing as defined by the Technical IPT, for example: fuze testing, sandbox testing, penetration testing, test (code) coverage metrics, and/or branch points.

Develop and execute test cases as informed by threat modeling, misuse, and abuse cases and assign to testing events as decided by the Technical IPT.

Perform regression testing and include regression suite tests negative test cases that fail if security mechanisms work properly.

Safety Critical Software Development For all safety critical or safety related software, the software shall be developed in accordance with the guidance provided in AOP-52 and shall include the following: In accordance with AOP-52, section 4, software that is considered as safety critical shall be developed to isolate the safety critical functionality. COTS software should also be isolated from safety-critical functions. The software life cycle should address the safety design considerations to include the extent and scope of interactions permitted between non-safety critical and safety critical components.

If an operating system (OS) is utilized for processing safety critical software, the safety critical functionality will demonstrate that any failure resulting from a defect in a program operating at a lower software criticality level cannot, under any circumstance, disrupt the operation of higher software-level functions.

System verification and validation of software safety-critical functionality shall include the following:

Bi-directional traceability evidence is required for all safety critical and safety related functionality to ensure each requirement has been incorporated and verified.

Requirements coverage analysis and structural code coverage analysis shall be performed for the appropriate level of rigor (LOR) of any safety critical or safety related function.

The use of deactivated code within safety critical or safety related software is allowed given that the functionality can be traced to a requirement and tested to ensure code is not executable in the target computer environment.

There shall be no dead code within safety critical software or safety related software.

Software Reliability The Contractor shall specify, collect, measure, analyze, and report software reliability measures to provide confidence that software is being matured to meet reliability requirements. This shall include the tracking of all mission critical PCRs identified during the software development lifecycle as specified in the SDP. The Contractor shall synchronize the software reliability measures and process with the Reliability Maintainability and Testability Case Management Plan (RMTCMP).

Software Reliability Demonstration As part of the developmental Formal Qualification Test (FQT) program, the Contractor shall conduct a software reliability demonstration and deliver a Software Reliability Demonstration Report due 30 days after completion of demonstration. The Contractor shall support the T&E IPT in establishing scope and success criteria of this test. Testing shall conform to the test requirements listed in the Software Test Plan and Software Test Description.

Change Requests (CR) The Contractor shall track, prioritize, and report all software defects, changes, updates or modification to the software and associated documentation resulting from reviews, analysis, and testing. The Contractor shall conduct a defect resolution process and Data Review Board (DRB) with Government representatives to review, prioritize, implement, verify, and close out any changes. The Contractor will coordinate with the Government on approving the priority levels and deferred defects and changes after FQT.

Software Cybersecurity The Contractor shall provide data/information in support of Cybersecurity Risk Management (RMF) processes including step six (6), Monitor Security Controls in accordance with DoD Instruction 8510.01. The Contractor shall support system vulnerability assessments including software assurance (SwA), Cooperative Vulnerability and Penetration Assessment (CVPA).

Contractor shall implement design changes or security measures to mitigate security risk imposed by identified vulnerabilities. Examples of security vulnerabilities may include access paths that would allow threats to trigger a component malfunction or failure at a time of the adversary’s choosing; access paths within the architecture and design that allow threats to circumvent integrity, confidentiality, and availability of the mission system through weaknesses in component design, architecture, or code. Examples of vulnerability analysis methods to discover system vulnerabilities may include SwA or CVPA. The Contractor shall implement design changes or security measures to mitigate security risks imposed by vulnerabilities identified from the vulnerability analysis.

System Engineering The Contractor shall implement systems engineering best practices for design, development, technical management, and fabrication of all CTSO INC1 system elements. These elements of the CTSO system include all hardware, software, equipment, facilities, processes, and procedures. The Contractor shall include stakeholder input from STPs in the systems engineering process. The Contractor shall show how stakeholder functional, physical, and operational performance requirements over the planned life of the system are being met within cost, schedule, and other constraints at system engineering reviews and system engineering deliverables. The Contractor shall create the functional baseline along with detailed specifications and associated Interface Control Documents (ICDs) of the various CTSO TA system components and present at the System Requirements Review (SRR) and System Functional Review (SFR).

System Engineering Reviews System Requirements Review (SRR) / System Functional Review (SFR) The Contractor shall conduct an SRR/SFR no later than (NLT) 45 days after agreement award. This review is intended to confirm that the Contractor’s requirements have been translated into system specific technical requirements and that system-level requirements are sufficiently well understood. The Contractor shall work with the Government IPTs to define entrance and exit criteria for the review. The presentation shall be delivered to the Government NLT 15 days before the review. This review shall be conducted at the Government’s facility at Picatinny Arsenal, NJ.

Preliminary Design Review (PDR) The Contractor shall conduct a PDR to assess the readiness of the Contractor’s development program to enter the detailed design phase. The Contractor shall present an established allocated baseline, risk assessments, and an updated program schedule highlighting system critical path drivers. This review shall be conducted nine months after agreement award. The Contractor shall work with Government IPT to define the entrance and exit criteria for the review. The PDR agenda and presentation shall be delivered to the Government NLT 15 days before the review. The PDR shall take place at the Contractor’s facility.

Critical Design Review (CDR) The Contractor shall conduct a CDR NLT six months after PDR and prior to delivering hardware for Government Testing. All design and manufacturing methods will be reviewed at this meeting.