bannerc

A. Introduction

B. Institutional Requirements

C. Project Software Requirements

D. Topics

E. Tools, References, and Terms

F. SPAN
(NASA Only)

Versions Compared

Old Version 45

changes.mady.by.user Tim Crumbley

Saved on

compared with

New Version 46

changes.mady.by.user Haigh, Fred

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

01. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
67. Software Assurance
Div
idtabs-1

1. Requirements

Excerpt

4.2.3 The project manager shall transform the requirements for the software into a recorded software architecture.

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. 

1.2 History

Click here to view the history of this requirement: SWE-057 History

1.3 Applicability Across Classes

Applicable c
a1
b1
csc1
c1
d0
dsc1
e0
f0
g0
h0

Div
idtabs-2

2. Rationale

Experience confirms that the quality and longevity of a software-reliant system is largely determined by its architecture. (See lessons learned NASA Study of Flight Software Complexity.

Swerefn
refnum571
) 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.
Swerefn
refnum131
 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.

...

idtabs-3

3. Guidance

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."

Swerefn
refnum131
More specifically, architecture is defined 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."
Swerefn
refnum210
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. Design rules are necessary for the enforcement of the architectural patterns for current and future software development (i.e., for open architecture systems).

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 reuse of design components and patterns between projects.

The software architecture is drafted during the early life-cycle phases of a project and baselined during Preliminary Design Review (PDR) (see Topic 7.8 - 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

Swerefn
refnum345
describes a model for creating software architectures by using the de-facto standard software modeling tool, UML (v2.0)
Swerefn
refnum139
. 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 and SWE-051 for more discussion on derived requirements.

NASA/SP-2007-6105, NASA Systems Engineering Handbook,

Swerefn
refnum273
and the Defense Acquisition University's Systems Engineering Fundamentals Guidebook
Swerefn
refnum174
 both provide more detailed discussions of requirements decomposition. The latter document includes several example templates for conducting decomposition activities. Some key concepts from these two references include: "Logical decomposition is the process for creating the detailed functional requirements that enable NASA programs and projects to meet stakeholders' needs."
Swerefn
refnum273
"The allocation process is accomplished by "arranging functions in logical sequences, decomposing higher-level functions into lower-level functions, and allocating performance from higher to lower-level functions." 
Swerefn
refnum174
"The process is recursive (repeatedly applied to lower levels) and iterative (repeatedly applied to the same products after fixes are made) and continues until all desired levels of the system architecture have been analyzed, defined, and baselined.
Swerefn
refnum273

As the software development team starts its effort, it organizes the activities based on these allocated and 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.

Software architecture is commonly organized using the concepts of "views" and "patterns." A view is a representation of a set of system components and the relationships among them. Views are used to describe the system from the viewpoint of different stakeholders, such as end-users, developers, or project managers.

Swerefn
refnum313
 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."
Swerefn
refnum191

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.

Swerefn
refnum224

SWE-057 calls for software architecture to be documented. The required content for the Software Design Description document includes the CSCI architectural design. The actual format for recording and describing the architectural concept is left to the software project team (all projects are different!). As a minimum, include the following:

  • 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.

See topic 7.7 - Software Architecture Description for additional information on the recommended kinds of content that usually appear in software architecture descriptions and for examples from a number of 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.

Swerefn
refnum295

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.

NASA-specific software measurement usage information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook. 

Additional guidance related to the software architecture development and documentation may be found in the following related requirements in this handbook:

...

Div
idtabs-4

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.

Swerefn
refnum131
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.

...

idtabs-5

5. Resources

5.1 References

...

groupconfluence-users

...

titleColorred
titleVisible to editors only

Enter the necessary modifications to be made in the table below:

...

SWEREFs called out in text: 131, 139, 174, 191, 210, 224, 273, 295, 313, 345, 571

SWEREFs NOT called out in text but listed as germane: none

...

Div
idtabs-6

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
    Swerefn
    refnum571
    : 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.

...

idtabs-7

7. Software Assurance

...

7.1 Tasking for Software Assurance

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

  2. Analyze the software architecture to assess whether software safety and mission assurance requirements are met.

7.2 Software Assurance Products

...

Note
titleObjective Evidence
  • Software design analysis results.
  • Software Architecture Review Board report and findings (if applicable).

...

titleDefinition of objective evidence

...

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

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 during Preliminary Design Review (PDR) (see Topic 7.8 - 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

Swerefn
refnum345
describes a model for creating software architectures by using the de-facto standard software modeling tool, UML (v2.0)
Swerefn
refnum139
. 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 and SWE-051 for more discussion on derived requirements.

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

  • 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.

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?
Page Editor: Tim Crumbley
NASA Official: Tim Crumbley
NASA Software Engineering Handbook - A service of the NASA Office of the Chief Engineer
NASA Privacy Statement
______________________________________________________________________________