New Products from NASA’s
Software Architecture
Review Board
Lorraine Fesq
Jet Propulsion Laboratory, California Institute of Technology
Flight Software Workshop
October 27-29, 2015
Johns Hopkins University/Applied Physics Laboratory
Annapolis, MD
Copyright 2015 California Institute of Technology. Government sponsorship acknowledged. The research was carried out at the Jet Propulsion
Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration.
Mission & Charter of SARB
SARB was established by NASA OCE in April 2009
Mission:
Manage flight software complexity
through better software architecture
Charter
• Provide constructive feedback to flight projects in the
formative stages of software architecting
• Focus on architectural improvements to reduce
and/or better manage complexity in requirements,
design, implementation, verification, and operations
• Spread best architectural practices, principles, and
patterns across flight software centers
• Contribute to NASA Lessons Learned
Software Architecture Review Board
2
NASA Software Architecture Reviews
Objectives
• Manage and/or reduce flight software
complexity through better software
architecture
• Help improve mission software reliability
and save costs
Approach
• Create a NASA-wide
software architecture
review board (SARB)
• Engage with flight projects
in the formative stages of
software architecture
Plan
 Prepare introductory document,
review process, review checklist,
documentation recommendations,
and sample problem statement
 Educate team on process
 Practice on flown missions
 Conduct real reviews
Software Architecture Review Board
3
SARB Team Members (as of October 2015)
Name
Expertise / Position
Michael Aguilar
Sponsor and NESC Software Discipline Expert, NASA Technical Fellow
in Software
Dan Dvorak
SARB co-Lead, Integrated Model-Centric Engineering (IMCE) team
JPL
Lorraine Fesq
SARB co-Lead, Fault Management Community of Practice Lead, 3101
JPL
Ken Costello
Aerospace and Software engineer, IV&V Program Chief Architect
IV&V
Michael Madden
Chief Scientist, Simulation Development and Analysis Branch
LaRC
Darrel Raines
Orion Flight Software System Manager
John Weir
FSW Lead for Space Launch System (and formerly, Ares I)
Kathryn Weiss
Senior Flight Software Engineer, JPL Flight Software Product Line
Cognizant Engineer
Jonathan Wilmot
Software architect, Flight Software Branch
Software Architecture Review Board
Affiliation
NESC
JSC
MSFC
JPL
GSFC
4
SARB Community of Practice Page
https://nen.nasa.gov/web/sarb
Software Architecture Review Board
5
SARB Documents
• Located on “Preparation for Review” page on SARB CoP
1. Contextually Driven Architecture Reviews
(outreach)
2. Project Problem Statement template
3. Preparing for a Software Architecture Review
4. Reference Architecture Questions
5. Architecture Review Checklist
6. Scope of Architectural Concerns
7. Quality Attributes Table
https://nen.nasa.gov/web/sarb/preparation
Software Architecture Review Board
6
Recommended Contents for
Software Architecture Descriptions
SARB advises starting with the SEI Template for a SW ADD,
in conjunction with the following to address
concerns/characteristics specific to the NASA FSW domain
•
•
•
•
•
•
•
•
•
•
Architecture Terminology
Mission Overview
Context Diagram, Context Description
Architectural Drivers
Critical Resources & Margins
Stakeholders & Concerns
Quality Attribute Analysis
Measures of Performance
Architectural Decisions & Rationale
Architectural Alternatives (Trade
Studies)
•
•
•
•
•
•
•
•
•
•
Multiple Views
Diagrams and Legends
Architectural Frameworks
Heritage Analysis/Software Reuse
Assumptions & Limitations
Architectural Patterns, Principles,
Invariants, Rules
Fault Management
Non-Concerns
References
SEI Template for Software Architecture
Documentation
Full document available at
https://nen.nasa.gov/web/software/sarb/guidelines
Software Architecture Review Board
7
SARB Documents
• Located on “Preparation for Review” page on SARB CoP
1. Contextually Driven Architecture Reviews
(outreach)
2. Project Problem Statement template
3. Preparing for a Software Architecture Review
4. Reference Architecture Questions
5. Architecture Review Checklist
6. Scope of Architectural Concerns
7. Quality Attributes Table
https://nen.nasa.gov/web/sarb/preparation
Software Architecture Review Board
8
Quality Attributes Table
• The Quality Attribute Table contains software
architecture quality attributes that are relevant to
the mission-critical real-time embedded systems.
Project specified
Attribute
Description
A design and
implementation
property of the
architecture and
applications
supporting their
Portability use on systems
other than the
initial target
system.
Aspects of Requirement Rationale
Real-time and
non-real-time
Operating
systems
Processor /
platform
The architecture
shall …
The architecture
shall…
1) Supports
both…
Operation
system
selection is…
The architecture Processors
shal…
and
platforms are
typical
variation
points…
Evidence
of/verification
Tactic to
achieve
Demonstrate execution
…
Demonstrate execution
on multiple operating
systems …
Is the architecture
Processor/Platform
interface abstraction
sufficient …
Application logic
is …
Standards and
abstractions
Project Prioritization Project intended
(NA, Low, Med, Hi)
variation
Standards and
abstractions
…
…
Full document available at
https://nen.nasa.gov/web/software/sarb/preparation
Software Architecture Review Board
9
Quality Attributes Table – excerpt
Attribute
Modifiability
Description and AKA terms
Aspects of
Requirement
Rationale
Evidence of/verification
Tactic to achieve
Modifiability refers to how well a
software system accomodates and
enables changes to it. All software
systems change to a lesser or greater
extent, and they do so from the early,
conceptual phase through the deployed
lifetime of the system. A system with
high, or good, Modifiability requires less
effort, and more predictable effort, to
make changes, or additions or deletions.
All software systems have an intrinsic
inertia, or resistance to change.
Achieving high Modifiability requires
anticipating change, understanding the
forms it will need to be able to take,
understanding how these forms of
change will conflict with initertia, and
designing in mechanisms to lessen that
conflict.
Ease of modification
to applications in a
deployed system
(whether deployed to
the actual mission
application, or
deployed to a testbed).
The architecture shall provide
mechanisms to modify applications in
a deployed system without change to
the state of unrelated applications.
Note: The procedure for deploying
modifications will vary in simplicity or
complexity, depending on the given
mission's needs and computing
environment. For example, for some
missions the process may involve a
reboot, for others not.
Supports orderly and safe system
modification due to faults or changes
to requirements, or to adapt to
differing mission modes. Supports
orderly and safe adaptation, in a
flight-like way, during testing, e.g. to
adapt to testbeds with varying
hardware configurations
The level of understanding and
documentation of the process of
modifying the system should be high. If
these capabilities are architected in up
front, as they should be, the complexity
to modify a deployed application is
much reduced.
Modifiability and extensibility must be a
native feature of the architecture. The
architecture must support explicit and
rigorous separation of applications or
components and ensure that applications
communicate only in well understood,
explicit and architecturally visible ways.
The mechanisms for supporting piecewise
replacement (at the app or component
level) of the software, both at the logical
level (for example, a defined protocol for
connecting and disconnecting
applications), and at the physical level (for
example, a dynamic link loader), must be
clearly identified, given the computing
environments of the system.
Ease of change to
applications at
development-time
The architecture shall provide
mechanisms to modify applications
during development without
modification to unrelated applications
or artifacts
The ability to make changes to one
application without affecting another
(and having confidence that that is
the case) results in a less chaotic
development environment, with less
un-planned work due to unexpected
side effects.
Statistics collected about development
schedules, and reasons for slippage,
should show a very low degree of
slippage due to unexpected side effects.
Design, deliver, and test the modification
mechanisms designed for ease of
modification to a deployed system (see
previous row) early. This will ensure that
these mechanisms are available for
modifications made during development
time.
Well identified and
understood variation
and extension points
The architecture shall support
variation and extension points within
the same mission.
Identifying and documenting
variation points eases the process of
making changes as the system
evolves, because it lessens or
obviates the need for analysis to
determine the feasibility and
difficulty of making the change. The
process of architecting the variation
points in promotes modifiability in
general.
Architectural documentation should
clearly describe the process of making
variations at known variation/extension
points. Later, specific tests should
demonstrate the exercise of the
process of making a variation.
The architecture must require the clear
and uniform identification of
parameterizable aspects and behaviors in
the software, as well as techniques and
mechanisms for controlling these
parameters.
Ease of adding new
application or
capabilities/functionali
ty
The architecture shall provide
mechanisms to add new
capability/functionality without
modification to unrelated applications
or their artifacts
Supports orderly and safe additions
of new applications, or extended
applications, to adapt to newlyidentified requirements or
desirements (such as the exploitation
of unforeseen science opportunities).
Architectural documentation should
clearly describe the process of adding a
new application or component to the
system. Specific testing should be run
that demonstrates adding an
application.
Design and implement mechanisms for the
orderly replacement of discrete parts of
the system, and require early testing of
these mechanisms. (These mechanisms
may be the same ones used to install a
change to an existing component of the
system.)
Synonyms of Modifiability are
Adaptability, Upgradeability, Variability,
Flexibility, Evolvability, Extensibility,
Extendibility
Software Architecture Review Board
10
Quality Attributes Table Use Cases
• The QA Table has at least three primary use cases
– Use by a software architect and project team to evaluate
the priorities of each QA for a specific project.
– Use during development – Developers implementing the
architecture need to be mindful of the “Tactic to achieve”,
“Evidence of/verification”, “Project Prioritization”, and
“Project intended variation” columns for each attribute
during the design and coding process
– Use in the review process to evaluate a software
architecture with respect to each QA in the Table and the
priorities established by the project
Full document available at
https://nen.nasa.gov/web/software/sarb/preparation
Software Architecture Review Board
11
SARB is a NASA-provided resource
• SARB is available to NASA projects “Free of
charge” for reviews
– Review feedback is provided to project only – handled
confidentially/discreetly
• Encourage your project to conduct a software
architecture review before PDR
– After PDR, it’s hard to make any substantive changes
Inquire about a review at
https://nen.nasa.gov/web/software/sarb or email
Lorraine.M.Fesq@jpl.nasa.gov
Software Architecture Review Board
12