04.01. Software Architecture

Software Requirements are transformed into a Software Architecture. Thus, the software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the properties of those components, and the relationships between them. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows the reuse of design components and patterns between projects.

In general, the software architecture relates the structure and behaviors of the software to the structure and behaviors of the system. This includes defining the relationships between software components and the operating environment. It also describes how the software will achieve necessary quality attributes (testability, reliability, reusability, safety, security, etc.). The software architecture also establishes architecture patterns for capabilities that cut across components (e.g., command processing, telemetry, FDIR, startup, cross-channel exchange). An architecture pattern is an abstract composition of elements and relationships whose instantiation generates a specified technical solution. Architecture patterns are sometimes expressed as design rules that ensure uniform implementation of those common capabilities.

SWE-057 - Software Architecture calls for software architecture to be documented. The required content for the 5.13 - SwDD - Software Design Description document includes the software architectural design. The actual format for recording and describing the architectural concept is left to the software project team (All projects are different!). 

Frequency Of This Activity

Changes to the Architecture may be necessary if there are changes in: 

• Mission objectives
• Software requirements
• Available technology improvements (hardware or software)
• Interfaces to other systems

04.01.1 Related SWEs

• SWE-057 - Software Architecture - 4.2.3 The project manager shall transform the requirements for the software into a recorded software architecture.
• SWE-143 - Software Architecture Review - 4.2.4 The project manager shall perform a software architecture review on the following categories of projects: 

  a. Category 1 Projects as defined in NPR 7120.5.
  b. Category 2 Projects as defined in NPR 7120.5, that have Class A or Class B payload risk classification per NPR 8705.4.

04.01.2 Related Work Products

• 5.13 - SwDD - Software Design Description - Minimum recommended content for a Software Design Description. 
• 7.08 - Maturity of Life Cycle Products at Milestone Reviews - This chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life cycle products and their maturity level at the various software project life cycle reviews.
• 7.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• 7.19 - Software Risk Management Checklists - tab 4 Software Design Phase checklist
• A.10 Software Peer Reviews and Inspections - Architecture documents are good candidates for a Peer Review

04.01.2.1 Related Process Asset Templates

• PAT-023 - Preparing for a SARB Checklist
• PAT-024 - Checklist for Choosing Off-The Shelf Software
• PAT-029 - Software Architecture Review Board Checklist
• PAT-030 - SARB Review Checklist with Guidance
• PAT-033 - TASKS NEEDING OBJECTIVE EVIDENCE

04.01.3 Related Topics

• 6.4 - Checklist for Choosing Off-The Shelf Software (OTS) - Checklist for Choosing Off-The Shelf Software (OTS) – Provides many questions to answer before choosing a COTS product that will be used across the project life cycle.
• 7.07 - Software Architecture Description - Recommend content for software architecture descriptions for NASA projects. 

04.01.4 Related SPAN Links

04.02. Software Design

NPR 7150.2 describes the software detail design activity, which is preliminary at project Preliminary Design Review (PDR) and baselined at Critical Design Review (CDR) (topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews), as occurring after the completion of the software architectural design process. This, in turn, is the "process of defining the architecture, components, modules, interfaces, and data" of a system or component. The software work product detailed design, which flows out of the software architectural definition (see SWE-057 - Software Architecture), and the preliminary design phase, is focused on defining the lower-level components, modules, and interfaces, and bringing them to a level of maturity sufficient to begin coding activities.

Frequency Of This Activity

Changes to the Design may be necessary if there are changes in: 

• Mission objectives
• Software requirements
• Architecture
• Available technology improvements (hardware or software)
• Interfaces to other systems

04.02.1 Related SWEs

• SWE-058 - Detailed Design - 4.3.2 The project manager shall develop, record, and maintain a software design based on the software architectural design that describes the lower-level units so that they can be coded, compiled, and tested.

04.02.2 Related Work Products

• 5.02 - IDD - Interface Design Description - Minimum recommended content for the Interface Design Description. 
• 5.07 - SDD - Software Data Dictionary - Minimum recommended content for the Software Data Dictionary. 
• 5.12 - SUM - Software User Manual - Minimum recommended content for the Software User Manual. 
• 5.13 - SwDD - Software Design Description - Minimum recommended content for a Software Design Description. 
• 7.08 - Maturity of Life Cycle Products at Milestone Reviews - This chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life cycle products and their maturity level at the various software project life cycle reviews.
• 7.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• A.10 Software Peer Reviews and Inspections - Design documents are good candidates for a Peer Review
• 7.19 - Software Risk Management Checklists - tab 4 Software Design Phase checklist

04.02.2.1 Related Process Asset Templates

• PAT-005 - Software Component Design Analysis Checklist
• PAT-006 - Design Practices for Safety
• PAT-007 - Checklist for General Software Safety Requirements
• PAT-008 - Safety Considerations for Design Peer Reviews Checklist
• PAT-015 - Detailed Design Checklist
• PAT-016 - Functional Design Checklist
• PAT-020 - Examples of Interface Problems
• PAT-021 - SADESIGN Checklist
• PAT-031 - Critical Design Analysis Checklist
• PAT-033 - TASKS NEEDING OBJECTIVE EVIDENCE

04.02.3 Related Topics

• 6.1 - Design for Safety Checklist - Lists some key practices for software design, particularly when designing safety-critical software.
• 8.01 - Off Nominal Testing - Guidance focusing on out of bounds parameters, failure scenarios, unexpected conditions, and capabilities that are typically considered as "must not work" functions.
• 8.02 - Software Reliability - The goal of SW reliability and maintainability is to assure that SW performs consistently as desired, when operating within specified conditions. This topic covers additional basic information on software reliability.
• 8.05 - SW Failure Modes and Effects Analysis - A "bottoms up" structured analysis method to help determine potential failures or hazards in the software design with guidance and forms.
• 8.07 - Software Fault Tree Analysis - A top-down analysis method to help identify the causes of presupposed hazards.
• 8.55 - Software Design Analysis - The Software Design Analysis product focuses on analyzing the software design that has been developed from the requirements (software, system, and/or interface). This topic describes some of the methods and techniques Software Assurance and Software Safety personnel may use to evaluate the quality of the architecture and design elements that was developed.
• 9.01 Software Design Principles - This topic contains the Guiding Principles that have been built over the years at NASA. These Principles are designed to help projects be successful by reducing the likelihood of defects.
• 9.02 Software Safety and Design Principles - This page contains the cross-references between elements of SWE-134 and the Software Design Principles.
• 9.03 Coding Standards - Implement a "secure" coding standard on all mission-critical software.
• 9.04 Command Receipt Acknowledgement - Design software to send a positive acknowledgement of command receipt.
• 9.05 Data Interface Integrity - Design software to verify the integrity of all inputs and outputs in the control system
• 9.06 Dead Code Exclusion - Establish a policy for eliminating unreachable code or mitigating the risk of any unreachable code.
• 9.07 Fault Detection and Response - In the software design, provide mechanisms to detect credible system faults and to react to these faults according to a pre-described plan.
• 9.08 Flight Software Modification - In the software design, provide mechanisms to detect credible system faults and to react to these faults according to a pre-described plan.
• 9.09 Incorrect Memory Use or Access - Design software to protect against incorrect use of memory.
• 9.10 Initialization - Safe Mode - Design flight software to initialize software and hardware to a known, safe, and deliberate state
• 9.11 Invalid Data Handling - Design software to handle invalid data appropriately.
• 9.12 Resource Margins - Establish and maintain quantitative margins for all critical resources, allowing for maturation of usage estimates through the life cycle.
• 9.13 Resource Oversubscription - Include a robust and well thought out response to resource oversubscription situations in the software design.
• 9.14 Resource Usage Measurement - Incorporate timely visibility into the use of computing resources into the software design.
• 9.15 Safe Transitions - Assert required preconditions and post-conditions at software transitions.
• 9.16 Thread Safety - Design interaction between threads to prevent inappropriate interference.
• 9.17 Toggle Commands - Design both internal and external commanding to place the system into an explicitly specified state.

04.02.4 Related SPAN Links