1. Requirements

1.1 Notes

A documented software architecture that describes: the software’s structure; identifies the software qualities (i.e., performance, modifiability, and security); identifies the known interfaces between the software components and the components external to the software (both software and hardware); identifies the interfaces between the software components and identifies the software components. Reference NASA’s Software Architecture Review Board (SARB) paper NTRS ID 20160005787, “Quality Attributes for Mission Flight Software: A Reference for Architects.”

1.2 History

1.3 Applicability Across Classes

2. Rationale

Experience confirms that the quality and longevity of a software-reliant system are largely determined by its architecture. (See lessons learned NASA Study of Flight Software Complexity. ) The software architecture underpins a system's software design and code; it represents the earliest design decisions, ones that are difficult and costly to change later.  The transformation of the derived and allocated requirements into the software architecture results in the basis for all software development work.

Software architecture:

• Formalizes precise subsystem decompositions.
• Defines and formalizes the dependencies among software work products within the integrated system.
• Serves as the basis for evaluating the impacts of proposed changes.
• Maintains rules for use by subsequent software engineers that assure a consistent software system as the work products evolve.
• It provides a stable structure for use by future groups through the documenting of the architecture, its views and patterns, and its rules.

3. Guidance

3.1 What is Software Architecture

In Software Architecture in Practice, Len Bass (et. al.,) architectural design is defined as "the process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system." More specifically, IEEE Std 1471-2000 defines architecture as "the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution." The architecture process, after defining the structural elements, then defines the interactions between these structural elements. It is these interactions that provide the desired system behavior. 

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.

See also Topic 8.02 - Software Reliability

3.2 How do Software Architecture and the Software Detailed Design Differ?

Software architecture focusses on how the software’s structure and interactions enable system behaviors and achieve desired quality attributes. The architecture is a high-level description of the software structure and of the software interaction with the operating environment. System requirements allocated to software can trace to architecture elements, but the architecture may not define a complete solution for all requirements. The architecture should use abstraction or patterns to represent multiple instances of common features but may not define their instantiations. Furthermore, the architecture may describe the content of data or messages (e.g., functions) without defining data types or signatures.

By contrast, the detailed design defines a technical solution for the derived software requirements with sufficient detail to begin coding. The detailed design decomposes software components defined by the software architecture into units, classes, data types, and functions. Furthermore, it documents all user-defined data types, functional signatures, and interfaces (both internal and external). The detailed design also defines all concrete instantiations of architectural abstractions. The detailed design should be traceable to both the derived software requirements and to the code.

Projects will sometimes delve into detailed design during development of the software architecture in order to abate or eliminate technical risks of high severity in the software. These details may appear in the software architecture description and blur the line between architecture and detailed design.

3.3 When and How Does One Define a Software Architecture?

The software architecture is drafted during the early life cycle phases of a project and baselined at Preliminary Design Review (PDR) (see 7.08 - Maturity of Life Cycle Products at Milestone Reviews). The drafting begins when the top-level (systems) requirements are collected and organized. The project's operational concepts document is prepared based on these top-level requirements. From this point, the project development team develops, decomposes, and sub-allocates these requirements to multiple and more narrowly focused activities. (Tarullo describes a model for creating software architectures by using the de-facto standard software modeling tool, UML (v2.0) . His approach fosters decomposition, which is a major practice used to control complexity in large (and small) software systems. The evaluation and sub-allocation of these requirements result in a hierarchical ordering of the complete set of requirements, which forms the basis and an initial structuring of the software architecture. Often this activity is accomplished by performing a functional or physical decomposition of the systems components and performance functions. As these allocated requirements are further matured and organized, a new set of statements evolves in the form of derived requirements. These derived requirements are nominally logical extensions of the originally specified requirements. See SWE-050 - Software Requirements and SWE-051 - Software Requirements Analysis for more discussion on derived requirements.

The key step is to transform these requirements into a logical and cohesive software architecture that supports the overall systems architecture for the NASA project. The team develops a software architecture to serve as guidance for the development of the components and systems-level software work products through a process known as architectural design.

In addition to the allocated and decomposed system requirements, the project also identifies key quality attributes, constraints, assumptions and limitations of the system that influence the software architecture. The Software Architecture Review Board (SARB) maintains the Quality Attribute Spreadsheet , an Excel workbook of quality attributes and associated architecture solutions on the NASA Engineering Network. Constraints, assumptions, and limitations may originate from the architecture of the computing hardware running the software, the operating environment, the development environment, stakeholders, the project leadership, or NASA policies, procedures, and standards. It is a best practice to develop the hardware and software architectures collaboratively in order to avoid hardware-imposed constraints and limitations that increase the complexity of the software architecture.

During architecture development, projects should identify and assess heritage or off-the-shelf software architectures, frameworks, middleware, components, or technologies for opportunities to meet key driving requirements while reducing cost, schedule, and risk. Such reuse or buy-vs-build decisions will define or constrain portions of the software architecture.

Software architecture is commonly expressed using the concepts of "views" and "patterns." A view is a representation of a set of system components and the relationships among them. Views describe the system from the perspective of different stakeholders, such as end-users, developers, testers or project managers.  Views are analogous to the different types of blueprints that are produced to describe a commercial building's architecture. Patterns in architectural design refer to the use of common or standard designs. "A pattern system provides, on one level, a pool of proven solutions to many recurring design problems. On another (level), it shows how to combine individual patterns into heterogeneous structures and as such, it can be used to facilitate a constructive development of software systems."

The resulting software architecture also allows for the following: The verification of the software components, the integration of work products into systems, and the integration of the software systems into the rest of the project's systems.

Software Architect Essential Activities

• • Understand what a system must do
  • Define a system concept that will accomplish this
  • Render that concept in a form that allows the work to be shared
  • Communicate the resulting architecture to others
  • Ensure throughout development, implementation, and testing that the design follows the concepts and comes together as envisioned
  • Refine ideas and carry them forward to the next generation of systems

3.4 Recording the Software Architecture

SWE-057 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!). See also SWE-058 - Detailed Design. As a minimum, include the following:

• The requirements, quality attributes, and constraints that influence the software architecture.  Collectively, these are called the “driving requirements.”
• Identification of the stakeholders and their concerns relevant to the architecture.
• Assumptions and limitations relevant to the architecture.
• An assessment of architectural alternatives.
• A description of the chosen architecture.
• Adequate description of the subsystem decomposition.
• Definition of the dependencies between the decomposed subsystems.
• Methods to measure and verify architectural conformance.
• Characterization of risks inherent to the chosen architecture.
• The documented rationale for architectural changes (if made).
• Evaluation and impact of proposed changes.
• Architecture rules or representations for domain specific concerns such as:
  • Architecture patterns, abstractions, and algorithms
  • Data representation and data management
  • Concurrent threads, processes, memory management
  • Real-time execution, throughput
  • Synchronization
  • Inter-process communication
  • Languages, libraries, operating systems
  • Verification and validation

Software architecture is not a one-time effort!

• Make software architecture a driving force throughout the life cycle
• Good architectures don’t step aside once development starts

Embrace well-architected software as a response to system complexity

• Weak architecture …
  • Can’t be analyzed or validated for correct behavior, except case by case
  • Can’t be changed with confidence, even to correct errors
  • Can’t be operated with confidence, other than the way it was tested
  • Can’t be reused easily or inherited from
  • Conduct software architecture reviews

See topic 7.07 - Software Architecture Description for additional information on the recommended kinds of content that usually appear in software architecture descriptions and for examples from several sources of outlines for documenting software architecture descriptions.

In situations where the software architecture does need to be changed, dependency models now offer the potential for maintaining the architecture over successive revisions during the software life cycle by specifying rules explicitly that define the acceptable and unacceptable dependencies between subsystems. The dependency structure model is an example of a compact representation that lists all constituent subsystems/activities and the corresponding information exchange and dependency patterns.

The Software Architecture Review Board, a software engineering sub-community of practice available to NASA users via the NASA Engineering Network (NEN), is a good resource of software design information including sample documents, reference documents, and expert contacts.

3.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.6 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

4. Small Projects

Software architecture is one of those non-coding activities that can improve the quality of the software. Small projects may want a less-formal, more-affordable method of development. In general, if software development involves a low-risk and highly precedented system, the project can skimp on architecture. If the development involves high-risk and novel systems, the project must pay more attention to it. Smaller, less risky projects may do just enough architecture by identifying their project's most pressing risks and applying only architecture and design techniques that mitigate them. Regardless of size, the resulting software architecture still needs to be adequately documented.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following:

• NASA Study of Flight Software Complexity. Lesson number: 2050: This March 2009 study identified numerous factors that led to the accelerating growth of flight software size and complexity that in turn lead to flight software development problems. In particular, the lesson learned states "Good software architecture is the most important defense against incidental complexity in software designs..."

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

7.2 Software Assurance Products

• Software Design Analysis
• Results of the software assurance architecture analysis confirm the necessary content, including any identified risks, and architecture issues.
• List of the software architecture features that impact safety and mission assurance.

  
  

  Software design analysis results. Software Architecture Review Board report and findings (if applicable).

7.3 Metrics

• # of software work product Non-Conformances identified by life cycle phase over time
• # of architectural issues identified vs. number closed
• # of safety-related non-conformances identified by life cycle phase over time

See also Topic 8.18 - SA Suggested Metrics

7.4 Guidance

Confirm that the project documents the software architecture.

The software architecture is drafted during the early life cycle phases of a project and baselined at Preliminary Design Review (PDR) (see Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews ). The drafting begins when the top-level (systems) requirements are collected and organized. The project's operational concepts document is prepared based on these top-level requirements. From this point, the project development team develops, decomposes, and sub-allocated these requirements to multiple and more narrowly focused activities. (Tarullo describes a model for creating software architectures by using the de-facto standard software modeling tool, UML (v2.0) . His approach fosters decomposition, which is a major practice used to control complexity in large (and small) software systems.) The evaluation and sub-allocation of these requirements result in a hierarchical ordering of the complete set of requirements, which forms the basis and an initial structuring of the software architecture. Often this activity is accomplished by performing a functional or physical decomposition of the systems components and performance functions. As these allocated requirements are further matured and organized, a new set of statements evolves in the form of derived requirements. These derived requirements are nominally logical extensions of the originally specified requirements. See SWE-050 - Software Requirements and SWE-051 - Software Requirements Analysis for more discussion on derived requirements.

Confirm that the software architecture addresses or contains the software structure, qualities, interfaces, and external/internal components.

• The requirements, quality attributes, and constraints that influence the software architecture.  Collectively, these are called the “driving requirements.”
• Identification of the stakeholders and their concerns relevant to the architecture
• Assumptions and limitations relevant to the architecture
• An assessment of architectural alternatives.
• A description of the chosen architecture.
• Adequate description of the subsystem decomposition.
• Data flow diagrams.
• Definition of the dependencies between the decomposed subsystems.
• Methods to measure and verify architectural conformance.
• Characterization of risks inherent to the chosen architecture.
• The documented rationale for architectural changes (if made).
• Evaluation and impact of proposed changes.
• Architecture rules or representations for domain specific concerns such as:
  • Architecture patterns, abstractions, and algorithms
  • Data representation and data management
• Concurrent threads, processes, memory management
• Real-time execution, throughput
• Synchronization
• Inter-process communication
• Languages, libraries, operating systems
• Verification and validation

Analyze the software architecture features to determine if any software architecture features impact safety and mission assurance.

• Do any hazards trace to any software architecture components? 
• Does any software architectural component(s) impact safety and mission assurance? For example, can a software partitioning approach impact safety and mission assurance?

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: