SATPC0031709 Tab 04 SOW.pdf

NASA Marshall Space Flight Center Date: 06/01/2023 Version 1

STATEMENT OF WORK

NASA Marshall Space Flight Center is conducting a pilot project on Model Based System Engineering (MBSE).

BACKGROUND

Model Based Systems Engineering (MBSE) is currently being used in support of design, development, test, and evaluation of spaceflight in various MBSE lifecycle configurations.

MBSE promotes the advancement of state-of-the-art SE technology in systems engineering by using proven open-source methodologies to integrate system design tools and models into a collaborative, web-based environment.

Marshall Space Flight Center is conducting a Technical Excellence (TE) effort to establish how the MBSE capabilities at MSFC could be developed and managed across the system engineering organizations in support of its programs/projects.

SCOPE

This task provides training and service to assist MSFC in accomplishing its MBSE goals.

Building on work done in a previous Proof of Concept (POC) NASA has determined to proceed with building out a Non-production environment in which their project customers can gain experience with OpenPDM integrations.

Project Requirements:

Planning:

1. Layout a vision for the Proof of Concept (POC) goals

2. Identification of stakeholders that defines the POC audience

3. Establish the NASA landscape that the System will operate within

4. Create a Capability map to demonstrate the use of PROSTEP OpenPDM & OpenCLM capabilities to meet NASA landscape and capability objectives

5. Develop a plan for the POC effort (schedule, touch points, interviews)

6. Establish the priority for each of the capability modules presented to NASA

The integration of the following Engineering applications:

• Doors to Jira Integration

- Scope includes the synchronization of Requirements data including Module, Requirements, and Sub Requirements with attributes and descriptions.

- Process is one way, triggered with reference to a module and will import or update.

Requirements in JIRA to match those in DOORS.

- Excludes Organizational data or VE data that may be included in DOORS.

• Doors to Teamwork Integration

- Scope includes the synchronization of Requirements data including Module, Requirements, and Sub Requirements with attributes and descriptions.

- Mapping from Doors to Cameo standard Requirements Schema

- Process is one way, triggered with reference to a Doors Module and will import or update.

Requirements in Teamwork Cloud to match those in DOORS.

• Teamwork to Jira

- Scope includes Functions, Architecture, System Design (mass roll-up, power roll-up, risk roll-up, etc.), and Requirements data hosted in Teamwork Cloud to be transferred to JIRA.

- Process is one way, triggered from the single root node to be determined at the workshop and include import and update functionality for architecture.

Required Software provided on an evaluation basis for 90 days from the date Software is delivered to Client

• OpenPDM Base

• OpenPDM Doors NG Connector (OSLC add-on)

• OpenPDM Cameo Teamcloud Connector

• OpenPDM Jira Connector

Scope of work for each integration:

• Requirements workshop to narrow down use cases, mappings, and scope for implementation.

• Implementation specification document

• Installation of OpenPDM & integration of OpenCLM Process Service and Connectors

• Configuration of OpenPDM/OpenCLM

• Implementation of OpenPDM activities for Export, Mapping, Import

• Integration testing

• Demonstration of the integration Assumptions:

• Exact scope of integration is to be determined during workshops based on effort and available budget.

• Integration scope is limited to available vendor APIs.

• Installation and implementation in a customer environment.

• PROSTEP consultants to get remote access to the customer environment.

• Integration to be triggered from OpenPDM Process Cockpit interactively, via REST API or time-based trigger within OpenPDM.

• Security Assertion Markup Language (SAML). An Extensible Markup Language (XML)-based framework for authentication and authorization between two entities: A Service Provider and an Identity Provider. The Service Provider agrees to trust the Identity Provider to authenticate users. In return, the Identity Provider generates an authentication assertion.

Documentation:

• Detailed documentation (including white papers, manuals, etc.) on all aspects of the system to be created is expected at the beginning of the project. This includes the methodology, overall architecture, distributed contexts, infrastructure requirements, functional elements and layout, protocols used for network, application and data-exchange and any other useful details. Early availability of this documentation is required to enable NASA to evaluate steps and identify any challenges towards integrating the system created by this project into the overall collection of the Agency's engineering resources and computational infrastructure. The documentation should have sufficient detail to enable a complete evaluation of its requirements, functionality, laypout and operations without having to go back to the vendor for clarifications.

• Documented APIs for scriptable/programmatic access to the system functions. This would help NASA in automating the management of the system and integrating it with other assets unique to the Agency.

• It is expected that by the end of the project Agency personnel will be trained or be able to operate and maintain the system, integrate additional data sources similar to the types already implemented, and extend basic functionality without requiring any extensive or continuous involvement of ProSTEP beyond the normal “technical support”.

Training:

40 Hours for NASA Personnel & Key Users to apply the Proof of Concept on a NASA Project.

Schedule for Proof of Concept July 1st, 2023 - December 31st, 2023