DSG-PLAN-004_Gateway_Configuration_and_Data_Management_Plan_Baseline.pdf

The electronic version is the official approved document.

Verify this is the correct version before use.

Gateway CM 09/05/2018

DSG-PLAN-004

INITIAL BASELINE

National Aeronautics and Space Administration RELEASE DATE: 09/05/2018

GATEWAY PROGRAM

CONFIGURATION AND DATA MANAGEMENT PLAN

Publicly Available: Release to Public Websites Requires Approval of Chief, Office of Primary Responsibility, and approval via the Scientific and Technical

Information (STI) process, if applicable

Revision: Initial Baseline Document No: DSG-PLAN-004 Release Date: September 5, 2018 Page: 2 of 37 Title: Gateway Program Configuration and Data Management Plan

REVISION AND HISTORY PAGE

Revision No.

Change No. Description Release

Date

- CR DSG-

C0003

Initial Release – Approved at Gateway Control Board (DCB) on 08/31/18

09/05/2018

Release Date: September 5, 2018 Page: 3 of 37

TABLE OF CONTENTS

SECTION PAGE

1.0 INTRODUCTION

1.1 PURPOSE

1.2 SCOPE

1.3 CHANGE AUTHORITY/RESPONSIBILITY

2.0 DOCUMENTS

2.1 APPLICABLE DOCUMENTS

2.2 REFERENCE DOCUMENTS

3.0 CONFIGURATION MANAGEMENT COMPONENTS

3.1 CONFIGURATION MANAGEMENT PLANNING AND MANAGEMENT

3.2 CONFIGURATION IDENTIFICATION

3.3 CONFIGURATION CONTROL

3.3.1 GATEWAY CONFIGURATION CONTROL BOARDS

3.3.2 GATEWAY CHANGE CONTROL PROCESS

3.3.3 CROSS PROGRAM/INTERNATIONAL PARTNER/NASA CONTRACTOR

CHANGE CONTROL PROCESS

3.3.4 CROSS PROGRAM CHANGE CONTROL BOARDS

3.3.5 CROSS PROGRAM INTEGRATED PRODUCTS

3.3.6 CHANGE CONTROL ROLES AND RESPONSIBILITIES

3.3.7 Waivers, Deviations, and Tailoring (Variances)

3.3.8 DEVIATIONS AND WAIVERS TO DSG SET OF REQUIREMENTS 19

3.3.9 DEVIATIONS AND WAIVERS PROPOSAL FORMAT

3.4 CONFIGURATION STATUS ACCOUNTING

3.5 CONFIGURATION VERIFICATION AND AUDITS

3.5.1 PRODUCT CONFIGURATION VERIFICATION

3.5.2 VERIFYING INCORPORATION OF APPROVED CHANGES

3.5.3 CM PROCESS AUDITS

3.5.4 CONFIGURATION MANAGEMENT OF DIGITAL DATA

3.5.5 RETROFIT REQUIREMENTS ......................................................... Error!

Bookmark not defined.

4.0 DATA MANAGEMENT AND CONTROL

4.1 DATA MANAGEMENT ORGANIZATION AND RESPONSIBILITIES

Release Date: September 5, 2018 Page: 4 of 37

4.2 DATA IDENTIFIERS, METADATA, AND LIFE CYCLE

4.2.1 LIFE CYCLE

4.3 DATA CLASSIFICATION AND MARKING

4.4 DATA CONTROL AND TRACKING

4.4.1 ROUTING/APPROVAL FLOW PROCESS

4.4.2 VERSION CONTROL AND TRACKING

4.5 PRODUCT DATA LIFE CYCLE MANAGEMENT (PDLM)

4.6 DATA STORAGE AND ACCESS CONTROL

4.6.1 DATA STORAGE

4.6.2 DATA ACCESS CONTROL

4.7 DATA DISPOSITION AND RECORDS MANAGEMENT

4.7.1 RETENTION OF RECORDS

APPENDIX

APPENDIX A ACRONYMS AND ABBREVIATIONS AND GLOSSARY OF TERMS

APPENDIX B OPEN WORK

TABLE

TABLE 2.1-1 APPLICABLE DOCUMENTS

TABLE 2.2-1 REFERENCE DOCUMENTS

TABLE 4.2-1 CORE SET OF METADATA

TABLE B1-1 TO BE DETERMINED ITEMS

TABLE B2-1 TO BE RESOLVED ISSUES

FIGURE

FIGURE 3.3.1-1 DSG BOARD STRUCTURE

FIGURE 3.3.2-1 DSG CONFIGURATION CONTROL CHANGE FLOW

FIGURE 3.3.4-1 CROSS PROGRAM CONFIGURATION CONTROL BOARDS

FIGURE 4.4.1-1 DM APPROVAL ROUTING/RELEASE PROCESS FLOW

Release Date: September 5, 2018 Page: 5 of 37

1.0 INTRODUCTION

1.1 PURPOSE

This Gateway Program Configuration and Data Management Plan (CDMP) defines the methodology, policies, and processes for implementing Configuration and Data Management (CDM) for Gateway, NASA Gateway Contractors, and each International Partner/Participant (IP/P). The CDM activities support the required development, maintenance, and control of the technical and programmatic documentation and data that defines the performance, physical, and functional characteristics of the Gateway hardware, software, and ground equipment. This document will be updated as necessary by Gateway and represents a careful application of the CM standards in SAE EIA-649B, National Consensus Standard for Configuration Management and SAE GEIA-859, Data Management Standards.

1.2 SCOPE/APPLICABILITY

This CDMP will be used to control of Gateway products under the authority of the Gateway Control Board (DCB), the Gateway Systems Engineering and Integration Control Board (DSCB), and to products under the control of a cross program configuration control board described in Section 3.3.1, Gateway Configuration Control Boards. The plans and processes described in this document address the configuration and data management of Gateway technical and programmatic data, information, configuration baselines, and records, consistent with NASA CM and DM principles. These are applied over a product’s lifecycle to document and control changes to performance, functional, and physical characteristics, as well as provide visibility into supplier activities. This CDM plan will define the roles and responsibilities of the CM discipline within Gateway, and it will provide a consistent set of principles and processes to manage functional, allocated, and product baselines.

The requirements of this Gateway CDMP are applicable to all Gateway elements as they develop and maintain their own CDMPs consistent with the Configuration and Data Management performance objectives and requirements documented in Agency standards.

Individual Element CM Plans may be utilized but must be compliant with the Gateway CDMP.

Element-unique CM requirements may be contained in an appendix to this plan; however, the Element CM Plans and/or appendices are controlled by the Element. Elements are subject to CM system audits to ensure compliance with this plan.

This plan may also be used in conjunction with Gateway’s contractors and international partners/participants. Each Gateway IP/P will use its own internal CM processes and procedures with their contractors and unique relationships between NASA Gateway Contractors are described in their contracts and respective CM Plans.

For purposes of this plan, the following definitions are provided to ensure consistency and avoid confusion. NASA applies to NASA Headquarters, NASA Field Centers and component facilities, and service providers to the extent they support Gateway. NASA Gateway Contractor is defined as all contractors having direct contracts with NASA Gateway. International Partners/Participants (IP/Ps) are the Canadian Space Agency (CSA), The European Space Agency (ESA), the Japan Aerospace Exploration Agency (JAXA), and the State Space Corporation Roscosmos. Gateway CM will integrate with IP/Ps and commercially-based

Release Date: September 5, 2018 Page: 6 of 37 elements through knowledge and awareness into their CM Plans and processes to ensure that they utilize and retain generally accepted CM practices and standards.

Gateway CM will integrate with the Exploration Systems Development (ESD) Programs through the cross program change control process described in Section 3.3.4. Cross Program Change Control Boards.

1.3 CHANGE AUTHORITY/RESPONSIBILITY

Proposed changes to this document shall be submitted via a Change Request (CR) to the Deep Space Gateway Control Board (DCB) for consideration and disposition.

All such requests will adhere to the Gateway Configuration Management Change Process.

The appropriate NASA Office of Primary Responsibility (OPR) identified for this document is Gateway Programmatic Integration and Strategic Analysis (PISA).

2.0 DOCUMENTS

2.1 APPLICABLE DOCUMENTS

The following data items including specifications, models, standards, guidelines, handbooks, and other special publications are applicable documents. The data items listed in this paragraph are applicable in the current approved baseline to the extent specified herein. Specific revisions of Gateway or Exploration Systems Development (ESD) controlled documents will not be annotated unless required to specify the boundaries of an incorporated agreement or requirement.

TABLE 2.1-1 APPLICABLE DOCUMENTS

Document Number

Document Revision Document Title

DSG-PLAN-001 Current Revision Gateway Program Plan (TBD-DSG-004-001) DSG-PLAN-007 Current Revision Gateway Program Systems Engineering

Management Plan (TBD-DSG-004-002) NPR 2800.1 B Management of Information Technology NPR 2810.1 B Security of Information Technology NPD 2190.1 A NASA Export Control Program NPR 2190.1 B NASA Export Control Program NPR 1600.1 NASA Security Program Procedural Requirements NID 1600.55 NASA Sensitive But Unclassified (SBU) Controlled

Information NPD 1440.6 H NASA Records Management NPR 1441.1 D NASA Records Retention Schedules NRRS 1441.1 NASA Records Retention Schedules

Release Date: September 5, 2018 Page: 7 of 37

Document Number

Document Revision Document Title

NPR 8900.1 A NASA Health and Medical Requirements for Human Space Exploration

SAE EIA-649 B National Consensus Standard for Configuration Management

SAE GEIA-859 A Data Management Standards

2.2 REFERENCE DOCUMENTS

The following documents contain supplemental information to guide the user in the application of this document.

TABLE 2.2-1 REFERENCE DOCUMENTS

Document Number

Document Revision

Document Title

DSG-CHTR-001 Current Revision Deep Space Gateway Control Board (DCB) DSG-CHTR-002 Current Revision Deep Space Gateway Systems Engineering and

Integration Control Board (DSCB) DSG-PLAN-006 Current Revision Gateway Program Risk Management Plan (TBD-

DSG-004-003)

NPR 7120.5

NASA Space Flight Program and Project Management Requirements

DSG-DM-10000 Current Revision Management of Information Assets HEOMD-004 Current Revision Human Exploration and Operations (HEO)

Requirements HEOMD-005 Current Revision Human Exploration and Operations (HEO) Concept of Operations NPR 7120.9 NASA Product Data and Life-Cycle Management

(PDLM) for Programs and Projects NPR 7123.1 Current Revision NASA Systems Engineering Processes and

Requirements

SAE GEIA-HB-

Implementation Guide for Configuration Management

HEOMD-002 Current Revision Human Exploration and Operations Mission Directorate Configuration Management Process

ESD 10001 Current Revision Exploration Systems Development Implementation Plan

ESD-MD-12002 Current Revision Exploration Systems Development Control Board (ECB) Charter

Release Date: September 5, 2018 Page: 8 of 37

Document Number

Document Revision

Document Title

ESD-MD-12024 Current Revision Exploration Systems Development Engineering Review Board (EERB) Charter

ESD 10005 Current Revision Exploration Systems Development Configuration and Data Management Plan

MPCV 72523 Current Revision Orion Multi-Purpose Crew Vehicle (MPCV) Configuration and Data Management Plan

GSDO-PLN-1001 Current Revision Exploration Ground Systems (EGS) Information and Configuration Management (ICM) Plan

SLS-PLAN-004 Current Revision Space Launch System (SLS) Program Data Management Plan

SLS-PLAN-008 Current Revision Space Launch System (SLS) Program Configuration Management Plan

3.0 CONFIGURATION MANAGEMENT COMPONENTS

3.1 CONFIGURATION MANAGEMENT PLANNING AND MANAGEMENT

Gateway has a role and responsibility in the performance of CM activities. The specific CM roles and responsibilities of the various CM processes are defined within and throughout this Configuration and Data Management Plan.

Personnel performing CM functions within Gateway should be familiar with the following:

• Five functions of CM

– Configuration Planning and Management

– Configuration Identification

– Configuration Control (Change Management)

– Configuration Status Accounting

– Configuration Verification and Audit

• Roles, responsibilities and authority of Gateway boards

• NASA and applicable industry CM standards

• CM procedures and methods

• CM tools

• Data retention and handling processes and procedures

CM is responsible for defining, planning, developing, and implementing information and configuration management policies, procedures, and guidance.

Release Date: September 5, 2018 Page: 9 of 37

Configuration Management identifies, controls, statuses, and verifies the consistency of a product and its attributes. Personnel with CM responsibilities perform this work in accordance with the performance objectives contained in CM Standard SAE EIA-649B by implementing NASA and applicable industry CM standards and NASA Engineering Processes and Requirements (per or consistent with DSG-PLAN-007, Gateway Systems Engineering Management Plan). Detailed work instructions guide all Gateway CM or Data Management (DM) work activities.

Gateway manages products identified with a Gateway number, via the DCB, DSCB, or other cross program configuration control board (CCB). Planning for configuration management of hardware and software products (Configuration Items (CIs)/Computer Software Configuration Items (CSCIs)) and data products specific to the Gateway Elements is delegated to Gateway Elements. The Elements are responsible for meeting the performance objectives contained in the Agency CM Standard SAE EIA-649B, for complying with the processes and procedures defined by Gateway CM, and for developing their own CDMPs accordingly.

Configuration management planning is common to all phases of the Gateway products lifecycle, although the detail upon which that management activity focuses varies depending on the lifecycle phase. CM planning consists of determining the CM concept of operation and strategy for the different phases of the lifecycle of a product and preparing or revising Configuration Management Plans accordingly. This includes, but is not limited to:

– Assignment of organizational CM functions and placement of processes and procedures

– Training of CM practitioners and for those who provide CM support or who have CM responsibilities

– Recognition and application of adequate resources for process implementation

– Measurements as a basis for reporting and continuous improvement

– Preparation and maintenance of the Gateway CDMP

3.2 CONFIGURATION IDENTIFICATION

Configuration Identification forms the foundation for all configuration management functional activities. It is a systematic process of selecting the product attributes, organizing associated information about the attributes, and stating the attributes. It is facilitated by CM in conjunction with systems engineering as part of an ongoing process of uniquely identifying and documenting performance, functional, physical, and management requirements and configuration of flight and ground hardware and software. Configuration Identification applies to systems from initial selection through design, development, fabrication, test, delivery, post-acceptance modifications, and operations. Configuration identification includes:

– Selection of CIs at the appropriate levels within the product structure to facilitate documentation, control, and support of the items and their associated data and documentation.

– Determination of the types of configuration documentation required for each CI to define its performance, functional, and physical attributes (including internal and external interfaces).

Release Date: September 5, 2018 Page: 10 of 37

– Issuance of unique identification numbers and ensuring they are affixed to the CIs and to their technical documentation that defines the CIs’ configuration and their effectivity designation.

– Establishment of control authority and board structure.

– Release of CIs and their associated configuration data

– Establishment of configuration baselines for CIs.

Configuration Identification provides for the creation of the product structure and the establishment of release baselines. The baselines consist of formally designated and controlled documents, databases, and products. The product structure represents the composition, relationships, and quantities of a product and its components. The appropriate control board must formally disposition all changes to the configuration baseline. The identification process establishes the rules and procedures for identifying all products. A product must be uniquely identified, so that its unique data and information can be managed.

The Gateway CDM Organization is responsible for:

– Ensuring the CM process is applied to each CI

– The baselines for each CI (functional, allocated, product, and managed technical and programmatic baselines) will be maintained through the Gateway control boards (DCB, DSCB)

– Documentation is maintained in the appropriate repository

3.3 CONFIGURATION CONTROL

After a baseline is established, it is essential that effective control be established to preclude any unauthorized changes to that baseline. There must be established procedures to ensure that each proposed change to the baseline, as well as any requested deviations or waivers, are completely described, coordinated, reviewed and evaluated for impacts and authorized for implementation by the appropriate Configuration Control Board authority. A Configuration Control Board Directive (CCBD) is utilized to disposition configuration changes, deviation/waiver requests, and applicable document Change Requests (CRs).

Gateway Configuration Control Boards are described in Section 3.3.1 and change authority delegations are documented in individual charters. Gateway maintains links to Program and Technical Baseline products in the Gateway Document Links Library.

Gateway CDM is responsible for implementation of a configuration control process by which changes to a baseline or product are controlled using a systematic, repeatable and measurable change process. The process consists of proposing, justifying, evaluating, coordinating, dispositioning, and implementing proposed changes. It encompasses establishing an initial baseline configuration for a CI and the implementation of only approved changes in the configuration after a configuration baseline is established for the CI.

3.3.1 GATEWAY CONFIGURATION CONTROL BOARDS

Gateway CM controlled products and changes to them are approved through a configuration control board (CCB) and its associated change process based on the governance documented

Release Date: September 5, 2018 Page: 11 of 37 in DSG-PLAN-001, Gateway Program Plan. Gateway manages its baseline and technical requirements through two primary boards; the Deep Space Gateway Control Board (DCB) and the Deep Space Gateway Systems and Engineering Integration Control Board (DSCB).

– The DCB is the CCB authority for products identified with a Gateway number, unless they are delegated to the DSCB, as indicated in the Gateway CM Product Listing. The Gateway Concept Formulation Lead chairs the DCB and has final authority over products dispositioned at the board. The DCB is established and controlled via a formal control board charter, which documents the authority, scope, membership, roles and responsibilities, by organization. Further details on the DCB can be found in the Gateway Implementation Plan and the DCB Charter, DSG-CHTR-001, at the location provided below:

https://sp.ndc.nasa.gov/sites/dsgt/dashboard/controlboards/SitePages/Home.aspx

– The DSCB is the CCB authority for the technical and programmatic portion of the integrated Gateway baseline delegated to it by the DCB. The DSCB ensures that the system design can meet the HEOMD Exploration Objectives, Requirements, Concept of Operations, and Utilization goals. The DSCB controls cross element products that impact two or more elements, are not under DCB/ESD Control Board (ECB) control, and are needed for technical Gateway execution. Technical changes that affect one or more of cost, schedule, or risk that are outside the authority of the DSCB will be elevated to the DCB. Further details on the DSCB can be found in the Gateway Program Plan and the DSCB Charter, DSG-CHTR-002, at the location provided below:

https://sp.ndc.nasa.gov/sites/dsgt/dashboard/controlboards/DSCB/SitePages/Home.asp x

– Each Gateway Element’s Control Boards establish and control that Element’s baseline and serve as the decision-making forum within that Element for policy, programmatic, and technical decisions. For further details on the ELCBs, refer to each Element’s Control Board Charters and CDM Plans.

See Section 3.3.4 Cross Program Change Control Boards for Gateway’s integration with ESD cross program control boards.

Gateway Board participation will include the International Partners when they are impacted stakeholders in the review and approval of Gateway products. When International Partners are a part of the DCB/DSCB (and Element CBs), an ITAR/SBU POC will review board presentation materials to ensure alignment with NASA policies and guidance documented in Section 4.6.2 Data Access and Control.

On occasion, DCB/DSCB-controlled products may be approved Outside-of-Board (OSB) at the discretion of the Board Chair. Guidelines for OSB include: the change is required to update or correct Gateway documentation consistent with the Gateway/Elements baselines or to define the implementation for a change previously approved by the DCB/DSCB; the change has been fully pre-coordinated, evaluated, and the impacts have been identified by all, and approval is recommended by all affected organizations; and the change constitutes a direction that the Board Chair has previously authorized via a Gateway Management Directive/Decision https://sp.ndc.nasa.gov/sites/dsgt/dashboard/controlboards/SitePages/Home.aspx https://sp.ndc.nasa.gov/sites/dsgt/dashboard/controlboards/DSCB/SitePages/Home.aspx https://sp.ndc.nasa.gov/sites/dsgt/dashboard/controlboards/DSCB/SitePages/Home.aspx

Release Date: September 5, 2018 Page: 12 of 37

Memorandum or determines should be expeditiously provided for implementing organizations without further evaluation. Documentation and communication of OSB decisions must include charts or decision packages, supporting information, along with associated impacts and actions.

FIGURE 3.3.1-1 GATEWAY BOARD STRUCTURE

3.3.2 GATEWAY CHANGE CONTROL PROCESS

The Gateway Configuration Control Process outlined in Figure 3.3.2-1, Gateway Configuration Control Change Flow, will be used for data products under DCB/DSCB control. Gateway Change Requests (CRs) are the mechanism used to evaluate and authorize proposed changes to DCB/DSCB controlled data products. The major phases of Gateway change processing include: Initiation, Screening, Evaluation, Comment Resolution, Change Integration, Preparation, Board/Panel Approval, Release, Closure and Archival.

Release Date: September 5, 2018 Page: 13 of 37

FIGURE 3.3.2-1 GATEWAY CONFIGURATION CONTROL CHANGE FLOW

Release Date: September 5, 2018 Page: 14 of 37

The configuration control change process shown above applies to all DCB/DSCB-controlled data products regardless of the tool the product resides in. Gateway products that are baselined/released are managed per life cycle and access controls within the tool. Any revisions of the product are revised/made from the original baselined product, or the last approved/released revision, leaving the original intact. The resulting object(s) are then updated and released to reflect the next revision.

Roles and responsibilities/activities for the process shown above include:

Change Package Engineer (CPE)

• The CPE identifies a data object for initial baseline or that requires a revision (1)

• All affected data objects are identified and updated or redlined with the proposed change

(2)

• If necessary, an internal review/evaluation may be conducted on the change(s) prior to formal Change Request (CR) release (3)

• The CPE submits formal CR to the Gateway CM Office for release for review (4)

• Following the CR review, the CPE dispositions comments received on the change (9)

• Technical Coordination Meetings (TCMs) are held to review all comments/dispositions with reviewers and to resolve any issues or non-concurs (10) and all stakeholders review the outcome (7)

• Following the TCM and review, the CPE either continues to work with stakeholders on any outstanding issues or makes the decision to proceed to the approving board, there may be reclamas (unresolved issues) that will go to the board for resolution (8)

• CPE prepares Board Decision Package for approving board (12)

• CPE is responsible for closing any board directed actions in the Board Change Directive

(14)

Change Package Manager (CPM)

• The CPM is a representative of the Gateway CM Office and assists the CPE throughout the CR process

• Once the CPE has determined the CR is ready for release, the CPM verifies that all affected data objects are included in the CR, assigns a CR identifier, and distributes the CR to impacted stakeholders to request evaluation (5, 6)

• The CPM assists the CPE in scheduling and managing the TCM process (10)

• Following the TCM and the decision to proceed to the approving board, the CPM schedules the board topic and works with the CPE to prepare Board Decision Package (12)

• If the board approves the CR, the CPM prepares the configuration control board directive which is signed by the board chair, documents any board actions, and issues the directive to impacted stakeholders (14, 11)

• If the board does not approve the CR, the CPE must decide whether to modify or cancel the CR and start the process over. The CPM closes or revises the CR and notifies stakeholders (15, 11)

Release Date: September 5, 2018 Page: 15 of 37

Detailed configuration control processes and procedures (i.e., Desk Instructions) (TBD-DSG- 004-005) are located on the Gateway Configuration and Data Management SharePoint site:

https://sp.ndc.nasa.gov/sites/deepspace/dashboard/pisa/CM/SitePages/Home.aspx

This site facilitates communication about requested changes and reported problems, and reduces the uncertainty around the existence, state, and outcome of a change that has been requested. Included, but not limited to, are: Gateway Forms and Templates; Requesting a Gateway Document Number; Initiating a Gateway Change Request (CR); Gateway Receipt and Release Desk (R&RD); CM Control for Requirements; Gateway Decision Packages for Board Approval; and answers to other Frequently Asked Questions (FAQs).

3.3.3 CROSS PROGRAM/INTERNATIONAL PARTNER/NASA CONTRACTOR CHANGE

CONTROL PROCESS

The Gateway Change Control Process integrates with Human Exploration Operations Mission Directorate (HEOMD), Exploration Systems Development (ESD), the Orion Multi-Purpose Crew Vehicle (MPCV) Program, the Space Launch System (SLS) Program, and the Exploration Ground Systems (EGS) Program, NASA Contractors and Gateway IP/Ps through the Cross- Program Change Control Process, which is owned by the Cross-Program Information and Configuration Management Working Group (ICMWG).

This process ensures that all applicable stakeholders are notified of change traffic that affects their products, systems, or processes and consists of the following steps:

1. Pre-coordination of changes among Cross Program/IP integrated working groups and forums.

2. A weekly review of upcoming changes (CR Look Ahead Report) by Gateway, ESD/Programs at the ICMWG indicating mandatory reviewers for CRs.

3. CR created by initiating organization using their change control process to the impacted organization(s).

4. Originating organization, impacted organizations initiate their review process within their organizations and send to appropriate organizations reviewers to complete the review in the agreed upon timeframe.

5. Originating organization receives consolidated comments from reviewers, stores, and dispositions comments per their internal procedures and processes.

6. If all organizations concur, the CR is approved at a configuration control board and implemented per the governance defined in DSG-PLAN-001 Gateway Program Plan and ESD 10001, ESD Implementation Plan. Resolution of dissenting opinions (e.g., non-concurs, reclamas) will be managed per the governance structure board charters.

7. The approving board issues a control board directive that all approved changes shall be incorporated into the affected baselines.

https://sp.ndc.nasa.gov/sites/deepspace/dashboard/pisa/CM/SitePages/Home.aspx

Release Date: September 5, 2018 Page: 16 of 37

8. Stakeholders respond to originating organization that affected changes have been incorporated and related tasks are completed/closed.

Configuration managed products on the ESD Integrated Product List (IPL) and Gateway Configuration Managed document listing are controlled by a Gateway configuration control board, a cross program configuration control board or a joint ECB/DCB. Change to configuration managed cross program products will be made via a Control Board Directive (see No. 7 above), which will contain the following:

– Associated CR # along with a brief description and scope of the change requested

– Impacts of the change approved at the Board – technical, cost, schedule, risk

– Actions assigned by the Board and their due date

– Signatures or verbal confirmation, recorded by the Board Secretariat, of concurrence/non-concurrence of the Board Chair, or in the case of multiple chairs, of affected Co-Chairs (signatures may be electronic)

– Board disposition of the change requested

Although all changes to cross program products are made by directive, the Cross-Program CM Process allows for distinct types of directives. Changes that are deemed suitable to proceed directly to directive without going through a formal review process are called Straight-to- Directive (S2D) The decision to utilize a S2D is made by a CCB, and involves all affected co-chairs of the CCB. Changes that have been approved via the Cross-Program CM Process, but that will not be incorporated until the next revision of the affected product, are called Hanging Directives. A hanging directive is posted with the current, released revision of the product as an approved change(s) to the product.

3.3.4 CROSS PROGRAM CHANGE CONTROL BOARDS

The joint ECB/DCB is the highest-level NASA cross program CCB. A joint ECB/DCB is authorized by the AA for the Human Exploration Operations Mission Directorate (HEOMD) and is documented in the ECB Charter (ESD-MD-12002) and the DCB Charter (DSG-CHTR-001).

The purpose of a joint ECB/DCB is to approve and resolve products/issues where both Explorations Systems Development (ESD) and Gateway are impacted and that may require funding transfers between the two, or that have an impact on cross program milestones. Further details on a joint ECB/DCB may be found in the board charters and in the Gateway Program Plan.

The Joint Integration Control Board (JICB) is an ESD Cross Program CCB composed of two or more of the Programs/ESD technical boards and is co-chaired by each Program’s Integration Lead and/or the ESD Cross Program Systems Integration (CSI) Lead. When a technical integration product/issue involving Gateway impacts an ESD Program, membership from the Deep Space Gateway Systems Engineering and Integration Board (DSCB) will be represented at the JICB. This is documented in ESD-MD-12024, ESD Engineering Review Board (EERB).

Release Date: September 5, 2018 Page: 17 of 37

FIGURE 3.3.4-1 CROSS PROGRAM CONFIGURATION CONTROL BOARDS

3.3.5 CROSS PROGRAM INTEGRATED PRODUCTS

Gateway and ESD manage products via two lists: 1) Enterprise Consolidated Product List (ECPL), and 2) Integrated Product List (IPL). The ECPL contains all the CCB-controlled products produced by Gateway, the ESD Programs, and ESD. The ECPL can be found at the following ICE wiki site:

https://nasa-ice.nasa.gov/confluence/display/OPPIP/IPL+with+MR+Report

The IPL is a list that captures Gateway products, along with ESD products, that are being developed and managed through the integration of Gateway into the Cross-Program Integration Team (CPIT) within ESD. The purpose of the IPL is to track integrated products (or documents) and to identify the lead office (or integrator) and authoritative board for each integrated product or shared document. The IPL identifies the program lead for the development of each product and the programmatic entry point for approval of the product.

Examples of cross program products include interface control documents, design and construction standards, range safety requirements, etc. The IPL can be found at the following ICE wiki site:

https://nasa-ice.nasa.gov/confluence/display/OPPIP/IPL+Standard+Report https://nasa-ice.nasa.gov/confluence/display/OPPIP/IPL+with+MR+Report https://nasa-ice.nasa.gov/confluence/display/OPPIP/IPL+Standard+Report

Release Date: September 5, 2018 Page: 18 of 37

3.3.6 CHANGE CONTROL ROLES AND RESPONSIBILITIES

Change Package Engineer (CPE): A CPE is a technical expert in the areas pertinent to a given proposed change. The CPE is responsible for the review and consolidation of comments from mandatory evaluators and recommendation of a change disposition to the appropriate control board.

Change Package Manager (CPM): The CPM is assigned from the Gateway CM team to assist the CPE with their duties. The CPMs also assist any of their team members with the CR life-cycle process, from CR initiation to closure of CCBD actions. They will assist any organizational personnel with their specific role in the CM process.

Gateway CM Receipt and Release Desk (R&RD): The Gateway R&RD is the authoritative point for all communication related to official CM products. This entity serves as the official location for submittal of change package data and associated documentation and serves as the only authorized notification of the release of approved Gateway baselined documentation.

Each Gateway Element will have its own R&RD functions.

Change Evaluators and Change Evaluation: Technical and programmatic personnel designated as mandatory evaluators for specific proposed changes are responsible for:

– Obtaining access to and utilizing Gateway Change Management Workflow (CMW) Tool for coordinating and evaluating assigned changes by their respective area of expertise and responsibility.

– Submitting a change evaluation spreadsheet with a recommended disposition and the technical, cost, schedule, and risk impacts to their respective area of responsibility.

– Coordinating their discipline team change evaluation spreadsheet content with their respective organization before submittal.

Board Directive Actionee Responsibility: Each person/organization assigned an action by a control board (board action or directive action) will be notified by Gateway CM or the Board Secretariat and be responsible for completing the assigned action(s) within the scheduled due dates and providing objective evidence of satisfactory completion of action(s) to the board secretariat (board actions) or the CPM (directive actions).

Data Quality Assurance: DQA is a function completed by the CPE to ensure that released documentation reflects the content approved by the control board. After a change has been approved by a CCBD, the CPE/DQA will verify that the approved changes have been incorporated and turn the document over to Gateway CM for a final review and formal release.

3.3.7 Waivers, Deviations, and Tailoring (Variances)

Waivers and deviations are the mechanisms used to authorize a variance (noncompliance) to a Gateway baseline requirement. For configuration items, this authorization for departure from a particular requirement is for a specific number of units or a specified period of time. Deviations and waivers will not be used to request configuration changes, i.e., baseline changes.

Release Date: September 5, 2018 Page: 19 of 37

Waiver – a mechanism used to obtain authorization for acceptance of a noncompliance with requirements after requirements are implemented.

Deviation – a mechanism used to obtain authorization for departure from a particular requirement prior to requirement implementation.

Either a waiver or deviation includes variances to current specified configurations (e.g., number of units, dimensions, values, period of time). Whether a waiver or deviation, both are configuration items and are processed using a single form, unique to Gateway and routed, elevated, approved, and maintained via the Gateway change management process.

Tailoring – a change to a standard or requirement (prior to implementation) for a specific implementation or program that meets the agreed-to-intent, but not the specifics of the original standard or requirement. Tailoring is authorized by a configuration control board or the Gateway Concept Formulation Lead when a “meets or exceeds the intent” assessment has been successfully completed and implementation will result in no or negligible risk to Gateway.

Tailoring is not a waiver or deviation. Approved tailoring will be documented in either a CCB Directive or in the Board Minutes.

3.3.8 DEVIATIONS AND WAIVERS TO HEO/GATEWAY SET OF REQUIREMENTS

The Gateway Change Control Process, as documented in Section 3.3.2, will be used by any Element requests to deviate or waive from HEO Gateway Requirements and Capabilities (HEOMD-004 and HEOMD-005) or Gateway Level 2 Requirements. When a deviation/waiver affects the same requirements/capabilities, which are specified in more than one paragraph/document within a Gateway requirement, only one deviation/waiver shall be processed, properly identifying the sources against which the deviation/waiver will be applicable.

Deviation/waiver requests, against Gateway requirements, will be processed on a Gateway Deviation/Waiver form (TBD-DSG-004-004) and go through the Gateway Change Control Process to the DCB and, if necessary, on to the Human Exploration Operations Mission Directorate (HEOMD) Associate Administrator (AA) of the Directorate Program Management Council (DPMC) for final approval. Waivers/deviations to a NASA requirement (i.e., NPR) may be processed by the Element(s), however, will go through the Gateway Change Control Process (Section 3.3.2) for review by impacted stakeholders and the DCB. If approved, the originating Element/Gateway will carry the waiver/deviation forward to the necessary Agency-level authorities for final approval.

Gateway will follow the standard documented in EIA-649B for variances in that approved variances are limited to the documented effectivity. Gateway will not use variance to manage and maintain design requirements. Gateway CM will track and initiate a review for variances extended beyond their initial documented and approved effectivity.

3.3.9 DEVIATIONS AND WAIVERS PROPOSAL FORMAT

Proposed deviations and waivers to Gateway requirements will be documented via a Request for Deviation (RFD)/Request for Waiver (RFW) using Gateway Form DSG-FORM-XXX (TBD- DSG-004-004) and will be submitted and processed in the same manner as a Change Request (CR). Each deviation and waiver will have its unique identification number.

Release Date: September 5, 2018 Page: 20 of 37

In addition to submitting Gateway Form DSG-FORM-XXX, a risk assessment, including a 5X5 risk matrix in accordance with DSG-PLAN-006, Gateway Risk Management Plan (TBD-DSG- 004-003) will be provided with technical rationale for acceptance, where appropriate and/or necessary.

3.4 CONFIGURATION STATUS ACCOUNTING

The Configuration Status Accounting (CSA) process establishes how to record, correlate, update, and report on product information status to effectively manage CIs, including maintaining a list of the approved configuration identification as defined in the approved baseline, approved changes, deviations and waivers to the baselines, and all pending change, deviations, and waivers to the baselines.

Gateway CSA is accomplished by utilizing real-time data from the Gateway Change Management Workflow (CMW) Tool. The CMW CSA provides reporting on configuration information that defines the approved baseline, approved deviations and waivers to the baseline as well as all pending changes, deviations and waivers to the baseline. The Gateway CM team is responsible for maintaining the data accuracy within the CMW using CSA reporting.

Supplier organizations CSA’s will include the status of the as-designed and as-built configurations of their CIs utilizing their CM processes and reporting. In addition, supplier organizations will ensure information about the newly released and approved configuration documentation is incorporated into the CSA system for reporting.

3.5 CONFIGURATION VERIFICATION AND AUDITS

Configuration verification and audit processes ensure that CIs/CSCIs and their associated configuration data have been properly identified, approved, released, and controlled throughout the Program lifecycle.

3.5.1 PRODUCT CONFIGURATION VERIFICATION

Verification is accomplished by inspecting documents, products, and records; reviewing procedures, processes, and systems of operations, to verify that the product has achieved their performance requirements and functional attributes; and verifying that the product designs are documented.

The following is required to baseline the product configuration:

a. Ensuring the product design provides the agreed-to performance capabilities

b. Validating the integrity of the configuration documentation or data

c. Verifying consistency between a product and its configuration documentation or data

d. Determining that an adequate process is in place to provide continuing control of the configuration

e. Providing confidence is establishing a product baseline

f. Ensuring a known configuration as the basis for operation and maintenance documentation, instructions, training, spare and repair parts, etc.

Release Date: September 5, 2018 Page: 21 of 37

The Gateway CM team support configuration verification per the following:

a. Conducting periodic CM audits of Elements and suppliers against their individual approved CM Plans to verify that a closed-loop system has been established to track all actions associated with the approval of CI documentation

b. Monitoring supplier compliance with contractual CM requirements

c. Supporting both the Functional and Physical Configuration Audits

The two formal configuration audits are the FCA and PCA. The FCA is used to verify that the performance requirements of the product have been obtained, while the PCA verifies the as-built configuration against its as-designed documentation.

An FCA/PCA or equivalent will be performed prior to the delivery of a CI/CSCI. The intent is to verify that the CI/CSCI requirements have been met and that the CI/CSCI as-built configuration meets the as-designed configuration. The Gateway CM Team, along with Safety & Mission Assurance and Systems Engineering will ensure that a PCA is complete and that the as-designed/as-built comparison establishes the product baseline for the CI/CSCI.

The basis for performing and documenting the FCA and PCA will be documented in future Gateway CM products.

d. Auditing the Acceptance Data Package (ADP) in conjunction with Safety & Mission Assurance (S&MA)

3.5.2 VERIFYING INCORPORATION OF APPROVED CHANGES

Implementation of a change of the product should be verified to ensure consistency between the product, its documentation, and its support elements. This process may involve a detailed audit of the product against its documentation, a validation of operations, maintenance, installation, or modification instructions, or a simple inspection. The choice depends upon the nature of the product and the complexity of the change.

For closed-loop tracking of Programmatic Requirements and Stakeholder Expectations, the Gateway Requirements Management and Systems Engineering Management Plan (TBD-DSG- 004-002) is used as the data configuration and management tool in conjunction with the Board-approved Change Directives managed and tracked by the Gateway CM team.

The successful accomplishment of Systems Engineering Reviews, the Functional Configuration Audit (FCA), and the Physical Configuration Audit (PCA), or similarly-paced milestone reviews are major contributors to the configuration verification task.

3.5.3 CM PROCESS AUDITS

The Gateway CM personnel may conduct periodic process audits of supplier CM functions to ensure compliance with CM requirements and contractual agreements. The audits address the adequacy of the CM process in meeting Gateway requirements for identification, control, accounting, and verification/audit. CM system audits will be done against both the supplier’s CM

Release Date: September 5, 2018 Page: 22 of 37 process/plan and the Gateway CM Plan to ensure compliance with Standard EIA-649B, used by

NASA.

3.5.4 CONFIGURATION MANAGEMENT OF DIGITAL DATA

CM principles will be applied to ensure the integrity of digital representation of product information and other data. Digital data is information prepared and maintained by electronic means and provided by electronic access, interchange, transfer, or on electronic media. The purpose and benefits of digital data CM are to ensure the integrity of digital data since one “document” can be represented in many equally valid forms. CM is required to retain multiple versions of files as necessary to recreate prior document revisions and provide a traceable history of each document. CM of digital data provides: effective file database management;

unique identification of documents, files and document repositories; retention of essential file and version relationships; known data status; and controlled access to digital data.

4.0 DATA MANAGEMENT AND CONTROL

4.1 DATA MANAGEMENT ORGANIZATION AND RESPONSIBILITIES

Gateway Data Management (DM) is the systematic collection, organization, and processing of information to provide consumers with secure, accurate and timely access to data. Gateway adheres to NPR 7123.1B, NASA Systems Engineering Processes and Requirements and NPR 2810.1B, Security of Information Technology, which describes the requirements and responsibilities for conducting information and data management. Detailed work and standard operating instructions describe the structure of information and data management functions, methods and procedures, and protection of data.

Data Management responsibilities include accepting data from Gateway Elements and releasing the data produced by Gateway to Gateway Element participants and stakeholders for use. Data Management ensures the data are processed, managed (version controlled), and released with the appropriate NASA security markings, data retention period, metadata, and stored in accordance with the security marking, in the appropriate repository in accordance with the Gateway Configuration and Data Management desktop instructions located on the Gateway CDM SharePoint site:

https://sp.ndc.nasa.gov/sites/deepspace/dashboard/pisa/CM/SitePages/Home.aspx

The Gateway CDM Office is responsible for managing the data Gateway produces and will monitor compliance to this plan throughout the entire lifecycle. Each Element is responsible for addressing Data Management in their individual plans.

4.2 DATA IDENTIFIERS, METADATA, AND LIFE CYCLE

Gateway will generate metadata associated with its data items through the suite of information system tools used, for example SharePoint, TechDoc, Windchill, Confluence Wiki, Cradle, etc.

Capturing metadata at the point of object creation is critical to ensuring that it will be captured at all levels and subsequently shared. Metadata describes the data and helps in the ease of retrieval, usage, and management of the data. Metadata is the key to managing electronic information. The application of metadata to data objects will ensure and support the

Release Date: September 5, 2018 Page: 23 of 37 organization of electronic data and authorized data exchange, facilitate interoperability and integration, and support archiving and preservation.

To facilitate interoperability and eliminate inconsistencies and redundancies, all data objects need to be uniquely identified and a standard/consistent set of core metadata and attributes (i.e.

Metadata Schema) established and implemented for data objects to support cross-application search and viewing of data. The table below lists the core set of metadata that will be used and managed within Gateway. For each attribute, the data owner will populate the field with the appropriate information e.g. the “format” attribute may contain ProE drawing or .xls. This core set of metadata aligns with the Elements and ESD/Programs metadata to assist in achieving interoperability and integration of information. Some of the attributes must always be used, others may be used depending on the object type and level of control required (data managed

vs. configuration managed). All attributes will be available for use and reporting. The data owner may define additional metadata extensions that are required by the object-type under consideration and not listed in the table below. Gateway CDM will be responsible for ensuring that the data owners associate the required metadata to DSG products.

TABLE 4.2-1 CORE SET OF METADATA

Attribute Owner File Path/Location

OPR

Program/Element Created Date (Date Elevated to DM Control) Unique Identifier Name/Title Flight Effectivity Access Restriction Record Indicator (Yes/No) Record Category Life Cycle State Key Words Description Released Date Format Version/Revision Relationship(s) (e.g., Parent/Child) Approval/Authority Authorization

Release Date: September 5, 2018 Page: 24 of 37

4.2.1 LIFE CYCLE

A data’s life cycle is the set of states (phases) in which the data moves through its evolution.

The different states indicate how the data should be utilized, managed, collected, stored, processed, and disseminated or shared within Gateway and other participant’s information systems. Data can be created or acquired, stored, and maintained, used, archived or purged (in accordance with records/plan schedules (NPR 1441.1). Defined automated life cycle processes will support the availability and accessibility of data at specified points in its life cycle. This data is accessed, edited, and transmitted by DSG approved applications and processes.

Data life cycle states for Gateway managed data (including documents) are as follows:

In Work – Data under the originator’s control only. In Work data will defined as data that not been reviewed, approved for technical sharing, or released under DM or CM control.

Documents that are In Work will be watermarked as “Draft”.

Under Review – Data that is within an approval process.

Accepted/Approved – Data that has been approved for its intended use and/or technical sharing or data that has been accepted from a data delivery.

Released – Data that has been baselined under CM control involving a CR and approval by a designated board or panel. Data that has been approved for use under DM control involving appropriate review and approval based on the product.

Cancelled/Rescinded – Data that is no longer required (applicable) or never…