/nasa-se

name: nasa-se-methodology
description: "NASA Systems Engineering methodology mapped to cloud operations. Use when planning, executing, verifying, or documenting OpenStack cloud infrastructure following NASA SP-6105 and NPR 7123.1 processes. Provides phase gate criteria, document templates, and cross-references for all 7 SE lifecycle phases applied to cloud deployment and operations."
user-invocable: true
allowed-tools: Read Grep Glob
metadata:
  extensions:
    gsd-skill-creator:
      version: 1
      createdAt: "2026-02-22"
      triggers:
        intents:
          - "nasa se"
          - "systems engineering"
          - "phase gate"
          - "sp-6105"
          - "npr 7123"
          - "cloud methodology"
          - "se engine"
          - "verification method"
          - "conops"
          - "semp"
        contexts:
          - "planning cloud deployment"
          - "writing operations documentation"
          - "verifying cloud infrastructure"
          - "conducting design review"

NASA SE Methodology for Cloud Operations

This skill maps NASA's SE Engine (17 common technical processes from NPR 7123.1) to cloud infrastructure operations. It provides the intellectual framework for the GSD OpenStack Cloud Platform project. Every document, procedure, and verification traces back to this methodology.

The SE Engine defines **how** engineering work is performed. The lifecycle phases define **when**. Together they ensure that cloud infrastructure is built with the same disciplined process NASA applies to spacecraft.

SE Engine Process Groups

System Design Processes (1-4)

| # | Process | SP-6105 | Cloud Operations Equivalent | |---|---------|---------|----------------------------| | 1 | Stakeholder Expectations Definition | SS 4.1 | Identify cloud consumers (developers, operators, security team, management) and capture service level expectations for uptime, performance, capacity, and security posture | | 2 | Technical Requirements Definition | SS 4.2 | Transform expectations into "shall" statements for each OpenStack service: functional capabilities, API response times, concurrent users, hardware constraints | | 3 | Logical Decomposition | SS 4.3 | Map cloud requirements to OpenStack services (compute to Nova, network to Neutron, storage to Cinder) and define service interaction architecture | | 4 | Design Solution Definition | SS 4.4 | Conduct trade studies (Kolla-Ansible vs DevStack, OVS vs OVN, LVM vs Ceph), select preferred design, produce configuration specifications |

Product Realization Processes (5-9)

| # | Process | SP-6105 | Cloud Operations Equivalent | |---|---------|---------|----------------------------| | 5 | Product Implementation | SS 5.1 | Deploy OpenStack services via Kolla-Ansible, validate container versions, verify configurations against requirements | | 6 | Product Integration | SS 5.2 | Wire Keystone to Nova to Neutron to Cinder into a functioning cloud following dependency order, validate cross-service interfaces | | 7 | Product Verification | SS 5.3 | Prove each service conforms to requirements using TAID methods: API tests, log analysis, configuration inspection, operational demonstrations | | 8 | Product Validation | SS 5.4 | Confirm cloud works for intended users under realistic conditions: real workloads, real users, real network traffic | | 9 | Product Transition | SS 5.5 | Hand off from deployment crew to operations crew with verified ops manuals, runbooks, monitoring dashboards, and trained operators |

Technical Management Processes (10-17)

| # | Process | SP-6105 | Cloud Operations Equivalent | |---|---------|---------|----------------------------| | 10 | Technical Planning | SS 6.1 | Cloud Engineering Management Plan: how the cloud is built, maintained, and evolved | | 11 | Requirements Management | SS 6.2 | Track requirements changes, maintain traceability from stakeholder needs through tests | | 12 | Interface Management | SS 6.3 | Service API contracts, network interfaces, storage interfaces between OpenStack components | | 13 | Technical Risk Management | SS 6.4 | Identify risks (hardware failure, network partition, security breach) and define mitigation plans | | 14 | Configuration Management | SS 6.5 | Git-controlled configs, change control process, baseline management for all OpenStack settings | | 15 | Technical Data Management | SS 6.6 | Documentation standards, archive strategy, access control for operational data | | 16 | Technical Assessment | SS 6.7 | Life-cycle reviews, progress tracking, cloud health monitoring against baselines | | 17 | Decision Analysis | SS 6.8 | Formal decision records for every design trade-off with alternatives evaluated and rationale documented |

Lifecycle Phase Mapping

Pre-Phase A: Concept Studies -- Cloud Architecture Assessment

• **SP-6105 Reference:** Section 4.1
• **NPR 7123.1 Reference:** Section 4.1
• **Cloud Equivalent:** Assess feasibility of proposed cloud architecture against available hardware, identify stakeholders, define Measures of Effectiveness
• **Key Activities:**
• Identify all cloud consumers and their service level expectations
• Conduct hardware inventory and resource assessment
• Develop Cloud Architecture Overview (ConOps)
• Classify project risk level (Type C-D per SP-6105 SS 3.11)
• Define Measures of Effectiveness (instance launch time, API availability, storage IOPS)
• **Deliverables:** Cloud Architecture Overview (ConOps), Stakeholder Register, Feasibility Assessment, Risk Classification
• **Review Gate:** MCR (Mission Concept Review) / Cloud Architecture Review
• **Phase Gate Criteria:**

1. All stakeholders identified with documented expectations 2. Hardware inventory complete with resource sufficiency confirmed 3. ConOps reviewed and approved by stakeholders 4. Risk classification documented with tailoring rationale

Phase A: Concept and Technology Development -- Technology Selection and Requirements

• **SP-6105 R