I.  OVERVIEW
                              
                              
A.   Concepts and Definitions

Software assurance is the planned and systematic set of
activities that ensures that software processes and products
conform to requirements, standards, and procedures.
"Processes" include all of the activities involved in
designing, developing, enhancing, and maintaining software;
"products" include the software, associated data, its
documentation, and all supporting and reporting paperwork.

The three mutually supportive activities involved in the
software life cycle are management, engineering, and
assurance.  Software management is the set of activities
involved in planning, controlling, and directing the
software project.  Software engineering is the set of
activities that analyzes requirements, develops designs,
writes code, and structures databases.  Software assurance
makes sure the management and engineering efforts put forth
result in a product that meets all of its requirements.

Software assurance is not an organization, but a set of
related activities.  It is unlikely that any NASA Center or
NASA contractor has a single organizational entity that
performs all of the functions defined in this guidebook.
The guidebook should be read as guidance to activities that
are vital to the success of a software project.  Some
considerations for organizational structuring to enhance the
probability of success are given in the section on
establishing a software assurance activity.

B.   Goals of Software Assurance

Software development, like any complex development activity,
is a process full of risks. The risks are both technical and
programmatic; that is, risks that the software will not
perform as intended or will be too difficult to operate,
modify, or maintain are technical risks, while risks that
the project will overrun cost or schedule are programmatic
risks. The goal of software assurance is to reduce these
risks.  For example, coding standards are set to specify a
minimum quality of code.  If no standards are set, there
exists some risk that the code will not come up to a minimum
usable standard, and that the code will require rework.  If
standards are set but there is no explicit process for
assuring that all code meets the standards, then there is
some risk that some coders will produce code that does not
meet the standards.  The assurance process involved is
quality assurance, and to have no quality assurance activity
is to increase the risk that unacceptable code will be
produced.

Similarly, the lack of a nonconformance reporting and
corrective action system increases the risk that problems in
the software will be forgotten and not corrected, or that
important problems will not get priority attention.  Other
risk-related examples can be provided to support all of the
activities in this guidebook.  The point is that software
assurance activities can help to reduce risks.

C.   Purpose of this Guidebook

The purpose of this Software Assurance Guidebook is to
provide assistance, in the form of guidance, to NASA
managers responsible for software acquisition and
development and for establishing software assurance
requirements.

The style of the guidebook is intended to be tutorial rather
than directive.  It is hoped that the reader will find the
following sections an easily understood introduction to
software assurance and a useful guide to formulating and
addressing software project needs related to assurance.

The remainder of this guidebook will touch on each major
activity within software assurance:  software quality
assurance, software quality engineering, verification and
validation, nonconformance reporting and corrective action,
safety, and security.  Section II, Establishing a Project
Software Assurance Activity, is designed to assist managers
in starting a new assurance activity or improving an
existing assurance program.