Attachment_2_-_Appendix_E_Architecture_21Aug14.pdf

N00024-14-R-6203

APPENDIX E

TO

ATTACHMENT 2

Architecture [CLIN 0010]

E-i

APPENDIX E

TO

ATTACHMENT 2

TABLE OF CONTENTS

1. SYSTEMS ENGINEERING 1

1.1 Studies and Analyses 1

1.2 Meetings, Integrated Product Teams (IPTs) and Working Groups (WGs) 1

1.3 System Requirements 1

1.3.1 Requirements Documentation 1

1.3.2 System Architecture and Design 2

1.3.3 Information Assurance (IA) 4

2. SYSTEM DEVELOPMENT 4

2.1 PCS Architecture Software Development 4

2.2 Problem Reporting 5

3. INTEGRATED LOGISTICS SUPPORT 5

3.1 Interactive Electronic Technical Manual (IETM) Source Data 5

E-1

APPENDIX E TO ATTACHMENT 2

STATEMENT OF WORK

FOR

ARCHITECTURE

[CLIN 0010]

The Contractor shall design, develop, test, integrate the AN/BYG-1 PCS architecture for all variants (V)1 – 10 under

CLIN 0010.

The Contractor shall use the AN/BYG-1 TI-16/APB-15 WCS system as the baseline for developing the TI-16/APB- 17 PCS architecture and shall ensure the TI-16/APB-17 PCS performance is in accordance with the Performance Specification for the Payload Control System (PCS) PMS4253-PCS-001 dated 9 May 2014 (Attachment 6). All tasks defined herein shall be accomplished and delivered in accordance with the IMS.

The Contractor shall ensure the PCS architecture is developed and delivered as part of TI-16/APB-17 PCS system.

The following Statement of Work (SOW) provides a summation of the efforts anticipated under this contract to support the TI-16/APB-17 architecture efforts.

The architecture documentation shall be developed and delivered as part of the TI-16/APB-17 PCS system unless specified is the following sections and CDRL exhibit.

1. SYSTEMS ENGINEERING

The Contractor shall provide a Systems Engineering Lead for the architecture efforts under this contract. The Systems Engineering Lead shall ensure the application of disciplined Systems Engineering processes and Integrated Process and Product Development (IPPD) principles toward the development of the TI-16/APB-17 PCS architecture supporting the final certified system configuration of the AN/BYG-1 SCCS.

1.1 Studies and Analyses

The Contractor shall assist the Government in developing strategies and studies, performing system engineering analysis, and developing implementation plans to ensure PCS architecture meet and/or sustain the specified performance. [CDRLs A010 and A011]

1.2 Meetings, Integrated Product Teams (IPTs) and Working Groups (WGs)

The Contractor shall participate in and/or support Government-established Integrated Product Teams (IPTs) and working groups supporting the architecture updates, integration, and performance assessment.

1.3 System Requirements

The Contractor shall assist the Government in defining, assessing and documenting requirements for the PCS architecture design. The Contractor shall maintain the PCS requirements in the Contractor Integrated Digital Environment database (i.e., Dynamic Object-Oriented Requirements System (DOORS)) with updates required for architecture as part of TI-16/APB-17.

1.3.1 Requirements Documentation

The Contractor shall provide requirements documentation for PCS architecture as part of the following TI-16 / APB- 17 documents:

• System/Subsystem Specifications (SSS) [CDRL A017]

• Specification Requirement Verification Matrix (SRVM) [CDRL A018]

E-2

The Contractor shall document the specific weapon/payload tubes and launcher equipment provided as GFE (Attachment 4) that will be utilized for each test in the SRVM.

1.3.2 System Architecture and Design

1.3.2.1 Modular Open Systems Architecture Approach

The Contractor shall establish and maintain a modular open systems architecture approach in accordance with the requirements of the DoD Open System Architecture Contract Guidebook, v1.1. Contractor shall ensure the following system architecture characteristics are maintained for the TI-16/APB-17 PCS:

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

b) Modular, Open Design – The Contractor shall develop and maintain a PCS architecture that is layered and modular and uses COTS/NDI hardware, operating systems, and middleware that utilizes non-proprietary or non-vendor-unique, key Application Programming Interfaces (APIs). The Contractor’s design approach shall be applied to all subsystems and components. The Contractor shall provide the Government (and/or Government support contractors) electronic access to its integrated development environment throughout the term of the contract.

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

For any changes to PCS baseline, the Contractor shall ensure frequent and continuous design disclosure to Navy designated third-party developers throughout the development/upgrade process.

1.3.2.2 System Design Documents

The Contractor shall provide the PCS architecture details as part of the following TI-16 / APB-17 documentation:

• System/Subsystem Design Description (SSDD) [CDRL A019]

• Software Requirements Specifications (SRSs) [CDRL A020]

• Software Design Description (SDD) [CDRL A021]

The Contractor shall ensure the above documents fully describe the architecture design with the overall software Computer Software Configuration Item (CSCI) structure, functional flows, and interface requirement details. The Contractor shall include separate sections that detail any unique variant or platform requirements.

The Contractor shall also generate SWFTS-level interface documentation changes, including Group Requirements Lists (GRLs), as required to support PCS architecture.

1.3.2.3 Technical and Design Reviews

The Contractor shall conduct the technical reviews to evaluate the proposed PCS Architecture design against requirements and identify any potential issues with the design approach. The technical and design reviews shall discuss and evaluate overall progress and the status of the architecture design updates. These technical and design reviews shall be defined in the IMS.

The Contractor shall provide the architecture technical and design reviews as part of the following TI-16/APB-17 technical and design reviews:

E-3

• System Requirements Review (SRR)

• Preliminary Design Review (PDR)

• Critical Design Review (CDR)

The Contractor shall prepare design artifacts as part of the technical reviews (SRR, PDR, CDR) for the PCS Architecture [CDRL A022].

1.3.2.4 PCS Architecture Study and Design

The Program Office’s intent is to develop and integrate a new PCS architecture supporting future payload capability while maintaining and sustaining baseline capability with the launcher, payloads and interfacing SWFTS subsystems. The new architecture will commence in the TI-16/APB-17 development CLIN 0005.

The Contractor shall provide a plan detailing the analysis, approach, recommended execution, and verification/validation methods for developing this new PCS architecture. [CDRL A010]

In designing the new PCS architecture the contractor shall consider the following:

Usability: PCS architecture will address the following usability components:

• Learnability: Minimize level of difficulty for users to accomplish basic tasks the first time they encounter the design

• Efficiency: Maximize speed of task performance for trained user

• Memorability: Maximize retention of user proficiency after sustained period of non-use

• Fault Tolerance:

o Prevention of operator error and system faults o Detection and isolation of faults o Operator notification of faults and system status o Recovery from faults

Modifiability: PCS architecture will address the following modifiability components:

• Maintainability: Minimize level of difficulty to develop, integrate, and deliver fault correction or improvements within PCS

• Extensibility: Minimize level of complexity to develop, integrate, and deliver future payload control services and applications within PCS

• Understandability: Maximize developer comprehension of system development constructs via documentation, common programming languages, and identifiable design patterns

• Openness: Maximize use of standard open system interfaces, protocols and components as opposed to specialized and proprietary solutions

• Portability: Minimize coupling of software components such that they can be easily transferred to various hardware and software environments

• Modularity: Maximize use of separate and discrete modular components

Testability: PCS architecture will address the following Testability components:

• Isolateability: Maximize degree to which the component under test can be tested in isolation

• Commonality: Components common to multiple PCS variants should be able to be tested in isolation as to minimize redundant testing efforts

• Automatability: Maximize degree to which it is possible to automate testing of the component under test

The plan shall encompass the entire proposed design, development and implementation effort for the new architecture and shall specify milestones and checkpoints, including (at a minimum) the following:

E-4

• Development and delivery of a Software Design Description (SDD) [CDRL A021]

• Checkpoints to review progress and adherence to requirements

• Entry and exit criteria for the applicable technical design reviews (SRR, PDR, CDR, etc.)

• Details included in the applicable technical design reviews (SRR, PDR, CDR, etc.)

• Proposed schedule for implementation and incorporation into TI-16/APB-17

Upon approval of the Contractor’s PCS Architecture execution plan and as directed by the Government, the Contractor shall develop and deliver a PCS Architecture Design technical report for describing the new PCS Architecture. [CDRL A010]

As part of this report, the Contractor shall describe the new PCS Architecture and the interface and interaction required with SWFTS subsystems and weapons/payload/launcher systems. The Contractor shall also address the following items in the technical report:

a) MOSA approach and the ability to accommodate new technology upgrades and future payloads

b) Modular vice unique system variant PCS and launcher/payload interface

c) Maintain and sustain baseline capability with launcher, payload, and interfacing SWFTS subsystems

d) Provide the flexibility to reallocate functions to different processors without major modifications to the system architecture

e) Use of industry supported, commercially accepted modern software languages

f) Approach to replace/remove non-industry supported or not commercially accepted software language code

(ex. ADA software language), unsupported products/ technologies and proprietary interfaces and middleware (ex. RADEX) from the software baseline

g) Approach to removal of software code that does not match or support a Performance Specification requirement (referred to as “dead code”)

h) Approach to utilizing open source tools and/or technologies

i) Interface and data exchange standards between component, module or system and interconnecting or underlying information exchange medium

j) Engineering, design and test documentation approach

k) The Usability, Modifiability, and Testability considerations identified in this section

l) Approach to enable third party development of payloads and/or modules

1.3.3 Information Assurance (IA)

The Contractor shall ensure the PCS architecture design and engineering processes employed in system design include IA considerations as delineated in the technical reference documents and the PCS Performance Specification, and that IA measures and design characteristics are correctly implemented in the PCS. Furthermore, the Contractor shall ensure that personnel are trained and appropriately certified in accordance with DoDD 8570.01 for providing IA functional services.

2. SYSTEM DEVELOPMENT

2.1 PCS Architecture Software Development

The Contractor shall maintain its software engineering process in support of PCS Architecture. The Contractor shall provide updates to the TI-16 / APB-17 Software Development Plan (SDP) as required to accommodate modifications in processes driven by, or additional processes required to support the architecture design development. The Contractor shall manage, develop, update, test and deliver the authorized PCS computer software updates in accordance with the SDP. [CDRL A023]

The Contractor shall provide the following software development services for new builds driven by changes authorized by the Government:

E-5

• Execute Code and Unit Test (CUT)

• Perform code review

• Assess, adjudicate, and resolve Problem Trouble Reports (PTRs)

• Generate and deliver software builds as necessary to support software development and integration requirements [CDRL A024]

• Generate Software Version Description (SVD) documents for the generated software builds [CDRL A025]

• Generate software configuration build procedures

• Provide Information Assurance Vulnerability Messages (IAVM) support

2.2 Problem Reporting

The Contract shall follow the same requirements as identified in Appendix A, TI-16/APB-17, Section 2.2 for the PCS architecture.

3. INTEGRATED LOGISTICS SUPPORT

3.1 Interactive Electronic Technical Manual (IETM) Source Data

The Contractor shall provide develop, update, and maintain, and deliver PCS Architecture design as part of the TI- 16/APB-17 baseline Interactive Electronic Technical Manual (IETM) source data to support Government or other Contractor modifications to the AN/BYG-1 IETM. [CDRL A029]. These updates shall include but are not limited to, functional descriptions, physical descriptions, operating procedures including power-up/down, display screen shots, display hot links and text hyper-links, which address all aspects of PCS operations and maintenance for each configuration consistent with similar PCS data contained within the AN/BYG-1 IETMs for TI-14 APB-13 provided as GFI (Attachment 3 GFI). The contractor shall develop source data that is S1000D compliant in a government approved S1000D database environment. TMCR NO. NDMS-090092-000 shall be used as a reference. The contractor shall provide subject matter expertise to support comment incorporation, desktop lab validations and verifications and provide single point of contact for the government and other members of the ILS working group in all matters relating to PCS IETM delivery, development and schedules.

Delivery schedule of IETM source data shall be documented in the contractor’s Integrated Master Schedule (IMS) and support the AN/BYG-1 Integrated Master Plan (IMP). The contractor shall participate in bi-weekly ILS working group forums.