![](media/image1.png){width="1.0729166666666667in"
height="0.9645833333333333in"}

ISD Software Management Plan /

Product Plan (SMP/PP)

For Class B & C Software

**Number:** 580-TM-033-01 **Approved By: (signature)**

**Effective Date:** August 25, 2005 **Name:** Joe Hennessy

**Expiration Date:** August 25, 2010 **Title:** Chief, ISD

**Responsible Office:** 580/Information Systems Division (ISD) **Asset
Type:** Template

**Title**: SMP/PP for Class B & C Software **PAL Number:** 1.2.6.1

  -------------- --------------------------------------------------------
  Purpose        The purpose of this document is to provide a template
                 for use in producing a SMP/PP for Class B and C mission
                 software as defined in NPR 7150.2, "NASA Software
                 Engineering Requirements." The template is a skeleton
                 SMP/PP intended for use by ISD personnel as the basis
                 for a project-specific SMP/PP.

  -------------- --------------------------------------------------------

+-------------+--------------------------------------------------------+
| Scope       | This template applies to all ISD mission software. ISD |
|             | mission software is typically in Class B or C, as      |
|             | defined in NPR 7150.2. (The NPR can be found at        |
|             | [http://nodis.hq.nasa.gov/.)]{.underline}              |
|             |                                                        |
|             | **Class B: Non-Human Space Rated Software Systems**    |
|             |                                                        |
|             | **Class C: Mission Support Software**                  |
+-------------+--------------------------------------------------------+

+-------------+--------------------------------------------------------+
| Style       | Text within the template that appears in this (style   |
| Conventions | name = "Normal") style is equally applicable to all    |
|             | SMP/PPs and should be included without modification.   |
|             | All document section headings should also be included  |
|             | without modification, although their style names vary  |
|             | depending on outline level.                            |
|             |                                                        |
|             | *Text in this style \[style name = "TAILORING          |
|             | ADVICE"\] within the template is advice on how to      |
|             | tailor the information in any specific section. As the |
|             | plan is developed, the generic \[TAILORING ADVICE\]    |
|             | text should be replaced with material that applies to  |
|             | the specific project, or deleted if it is general      |
|             | advice.*                                               |
+-------------+--------------------------------------------------------+

+-------------+--------------------------------------------------------+
| General     | All components of the SMP/PP table of contents must be |
| Tailoring   | addressed, but the level of detail is left up to the   |
| Conventions | Team based on software complexity and the customer's   |
|             | needs and expectations. The length and level of detail |
|             | of the SMP/PP should be commensurate with the scope    |
|             | and complexity of the project. Section headings may be |
|             | added where necessary, but existing headings should    |
|             | not be modified or deleted. If a particular section is |
|             | not applicable to the specific SMP/PP under            |
|             | production, that fact should be noted under the        |
|             | section heading, together with a brief explanation.    |
|             |                                                        |
|             | Some items of the table of contents are processes that |
|             | must be included in the SMP/PP by reference to         |
|             | approved processes contained in the GSFC Process Asset |
|             | Library at                                             |
|             | [http://so                                             |
|             | ftware.gsfc.nasa.gov](http://software.gsfc.nasa.gov/), |
|             | or by direct inclusion in the SMP/PP. If new processes |
|             | are included in the Plan, they must meet the criteria  |
|             | for each specific process specified in Appendix B of   |
|             | the Product Development Handbook.                      |
|             |                                                        |
|             | The following disclaimer appears on all pages of the   |
|             | template: "Printed copies of this document are for     |
|             | REFERENCE PURPOSES ONLY! The only controlled copy of   |
|             | this document is located on-line at                    |
|             | [http://xxx.yyy.zzz"](http://xxxxxxxx/). This          |
|             | disclaimer should be modified to contain the           |
|             | appropriate URL, but should not be removed.            |
|             |                                                        |
|             | Finally, in the target Plan, this entire section       |
|             | (Document Header, "Purpose", "Scope", "Style           |
|             | Conventions", "General Tailoring Guidelines", and      |
|             | "Template Change History") should be deleted.          |
+-------------+--------------------------------------------------------+

  -------------- --------- --------- ----------------------------------------
  Template       Version   Date      Description of Improvements
  Change History                     

                 1.0       8/23/05   Approved by the ISD CCB.
  -------------- --------- --------- ----------------------------------------

*\[Name of Code xxx\]* Branch

*(NASA GSFC Code 58x)*

***\[Mission Name (Acronym)\]***

***\[Software Project Name (Acronym)\]***

**Software Management Plan (SMP) / Product Plan (PP)**

**SMP/PP Version: *\[xx\]***

**SMP/PP Date: *\[yy\]***

**Software Manager: *\[Software Manager Name\]***

SIGNATURES

**Prepared by:**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Aaa A. Aaaaa/58x Date

*\[Software Project Name\]* Software Product Development Lead

**Approved by:**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Aaa A. Aaaaa Date

Customer Representative

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Aaa A. Aaaaa /58x Date

*\[Branch name\]* Branch/Head

*\[Insert additional signatures of stakeholders as needed to document
their commitment to this plan.\]*

PLAN UPDATE HISTORY

*\[This table shows the update history for the SMP/PP. Insert version
designations, dates, and descriptions for the various version of this
SMP/PP, along with the numbers of updated pages for each version.\]*

  -------------------------------------------------------------------------
  Version   Date      Description                          Affected Pages
  --------- --------- ------------------------------------ ----------------
                      .                                    

                                                           

                                                           

                                                           

                                                           
  -------------------------------------------------------------------------

*\[The Table of Contents is generated from section headings. Highlight
the table and press the F9 key to update it in the project-specific
SMP/PP.\]*

TABLE of CONTENTS

[1.0 Introduction 1](#introduction)

[1.1 Background 1](#background)

[1.2 Document Organization 1](#document-organization)

[2.0 Customer Agreement 2](#customer-agreement)

[2.1 Customer Identification 2](#customer-identification)

[2.2 Customer Goals and Objectives 2](#customer-goals-and-objectives)

[2.3 Customer Requirements 2](#customer-requirements)

[2.4 Customer Schedules 2](#customer-schedules)

[2.5 Customer Deliverables 2](#customer-deliverables)

[2.6 Acceptance Criteria 2](#acceptance-criteria)

[2.7 Customer Training 3](#customer-training)

[2.8 Post-Delivery Maintenance 3](#post-delivery-maintenance)

[2.9 Customer-Supplied Elements 3](#customer-supplied-elements)

[2.10 Customer Involvement 3](#customer-involvement)

[2.11 Customer Requirements Review & Update Process
3](#customer-requirements-review-update-process)

[2.12 Resources Needed 3](#resources-needed)

[3.0 Software Management Approach 5](#software-management-approach)

[3.1 General Development Approach 5](#general-development-approach)

[3.2 Work Breakdown Structure 5](#work-breakdown-structure)

[3.3 PDT Information 5](#pdt-information)

[3.3.1 Product Development Team (PDT) Charter
5](#product-development-team-pdt-charter)

[3.3.2 Organization 5](#organization)

[3.3.3 Roles, Responsibilities, Authority, & Accountability
6](#roles-responsibilities-authority-accountability)

[3.3.4 Stakeholder Involvement 7](#stakeholder-involvement)

[3.3.5 Training Plan 7](#training-plan)

[3.4 Procurement 8](#procurement)

[3.5 Risk Management 8](#risk-management)

[3.6 Software Safety 8](#software-safety)

[3.7 Software Security and Privacy 9](#software-security-and-privacy)

[3.8 Independent Verification and Validation (IV&V)
9](#independent-verification-and-validation-ivv)

[3.9 Review Program 9](#review-program)

[3.10 Overall Schedule 9](#overall-schedule)

[3.11 Status Tracking 10](#status-tracking)

[3.12 Data Management (DM) 10](#data-management-dm)

[3.13 Project Measures 10](#project-measures)

[3.14 Key Issues, Decisions, and Rationale
13](#key-issues-decisions-and-rationale)

[3.15 Lessons Learned 14](#lessons-learned)

[4.0 Software Technical Approach 15](#software-technical-approach)

[4.1 Derived Requirements 15](#derived-requirements)

[4.2 Development Strategy 15](#development-strategy)

[4.2.1 Development Life-Cycle 15](#development-life-cycle)

[4.2.2 Development Process 15](#development-process)

[4.2.3 Development Environment 15](#development-environment)

[4.2.4 Make/Buy Approach 15](#makebuy-approach)

[4.2.5 Customer-Supplied Products Approach
16](#customer-supplied-products-approach)

[4.2.6 Rights and Approvals 16](#rights-and-approvals)

[4.2.7 Prototyping Approach 16](#prototyping-approach)

[4.3 Product Design 16](#product-design)

[4.4 Build Approach 16](#build-approach)

[4.5 Verification and Validation 16](#verification-and-validation)

[4.5.1 Product Verification 16](#product-verification)

[4.5.2 Statistical Techniques 17](#statistical-techniques)

[4.5.3 Incoming Inspection and Test 17](#incoming-inspection-and-test)

[4.5.4 Product Validation 17](#product-validation)

[4.6 Peer Review/Inspection Process 17](#peer-reviewinspection-process)

[4.7 Documentation 18](#documentation)

[4.8 Product Delivery 18](#product-delivery)

[4.9 Product Maintenance 18](#product-maintenance)

[5.0 Product Control and Assurance 19](#product-control-and-assurance)

[5.1 Configuration Management (CM) 19](#configuration-management-cm)

[5.2 Control of Nonconforming Products and Corrective Action
19](#control-of-nonconforming-products-and-corrective-action)

[5.3 Control of Test Software and Hardware
19](#control-of-test-software-and-hardware)

[5.4 Control of Customer Supplied Products
19](#control-of-customer-supplied-products)

[5.5 Software Quality Assurance 20](#software-quality-assurance)

[Appendix A: Acronyms 21](#appendix-a-acronyms)

[Appendix B: System/Subsystem Classifications
23](#appendix-b-systemsubsystem-classifications)

[Appendix C: Tailoring Matrix for Compliance with
24](#appendix-c-tailoring-matrix-for-compliance-with)

[NPR 7150.2 24](#npr-7150.2)

# Introduction

This document is the Software Management Plan/Product Plan (SMP/PP) for
development of the *\[software project acronym\]* system.

The major goals for this document are:

> \(1\) To describe **what** products will be delivered as the
> *\[software project acronym\]* system.
>
> \(2\) To define **who** is responsible for producing the products.
>
> \(3\) To describe the baseline **schedule** for completing the effort.
>
> \(4\) To specify the estimated resources needed (**cost** and/or
> effort) to produce the software, as a function of time.
>
> \(5\) To describe **how** and **where** the work will be carried out.
>
> \(6\) To reach a mutual understanding and agreement with our customer
> and other stakeholders on items (1) through (5).

*\[Use the paragraph above as is, or add project-specific information
about the purpose of this plan.\]*

## Background

*\[Include a brief description of what larger effort/activity this
Product Development Team (PDT) is supporting (e.g., a high-level
overview of the mission) and how this product fits into the larger
picture. This should provide a context for the more detailed material to
follow. If the product is a component of a larger system, include a
diagram showing how the component fits into the system.\]*

## Document Organization

Section 1 of this document presents introductory material and an
overview of the software system to be developed.

Section 2 (Customer Agreement) summarizes the requirements,
deliverables, and other mutually agreed aspects of the relationship
between the customer and the software project.

Section 3 (Software Management Approach) describes how the development
process will be managed.

Section 4 (Software Technical Approach) describes the technical approach
to developing, delivering, and maintaining the software products.

Section 5 (Product Control and Assurance) describes how configuration
management will be performed and how the quality of the software system
will be assured.

Appendix A (Acronyms) defines the acronyms and abbreviations used in
this document.

Appendix B (System/Subsystem Classifications) provides the
classification of the software system and subsystems to be developed, as
required by NPR 7150.2.

Appendix C (Tailoring Matrix for Compliance with NPR 7150.2) shows the
project's compliance with the requirements of NPR 7150.2, "NASA Software
Engineering Requirements," and provides the tailoring information
necessary for Independent Technical Authority (ITA) approval of
variants, waivers, or exceptions to the NPR.

# Customer Agreement

This section describes the *\[software project acronym\]* Product
Development Team's (PDT) understanding of the products to be developed,
the schedule for development, the resources required, and mechanisms for
communicating with the customer. The purpose of this section is to
expose these items to the customer as a means of negotiating and
documenting a mutual understanding. The customer's signature on the
signature page indicates agreement with this section.

## Customer Identification

*\[Identify the primary customer for the software to be developed.
Normally, this will be the Mission Project or other organization that is
providing funding for the development effort, has specified the
requirements, and will be responsible for accepting the final
software.\]*

## Customer Goals and Objectives

*\[List the customer's primary goals and objectives for the software to
be developed. Essentially this amounts to a very high-level statement of
the major requirements, probably no more than one or two paragraphs.
Also list any special things that the customer wants to accomplish (e.g.
rapid turn around, new architecture, special COTS requirements,
experiments, etc.) through the PDT's activities.\]*

## Customer Requirements

*\[This section should reference (preferred) or list the high-level
requirements [specified by the customer]{.underline}, and should include
any [customer-specified]{.underline} standards or interface control
documents (ICDs) with which the software system must comply. Do not
include derived technical interface documents or databases here;
reference them in Section 4.1.\]*

## Customer Schedules

*\[Reference or list all [customer-specified]{.underline} schedule
requirements, including such items as documentation, releases and
reviews.\]*

## Customer Deliverables

*\[List the [customer-specified]{.underline} products to be delivered
for each phase of development, including software, hardware, licenses,
documentation, etc. List any [customer-specified]{.underline} delivery
medium and method of delivery for all products listed. (Describe those
media/methods that are NOT specified by the customer in Section 4.8. See
GPR 6400.1 for details.) List any [customer-specified]{.underline}
product delivery destinations for all products listed.\]*

  ----------------------------------- ------------------ -----------------
  **Deliverables by Phase**           **Medium/Method\   **Delivery\
                                      of Delivery**      Destination**

                                                         
  ----------------------------------- ------------------ -----------------

## Acceptance Criteria

*\[Reference (preferred) or describe the customer's criteria for
determining when the product is completed (e.g., \"When will the
customer accept the product?\"). This is usually demonstrated by having
a satisfactorily completed acceptance test matrix/set of acceptance test
plans. The customer\'s verbal acceptance is not sufficient.\]*

## Customer Training

*\[Specify who (from customer organization) is to be trained, estimate
how many are to be trained, and identify the location and nature of
training.\]*

  ----------------------------------- -------- -----------------------------
  **Customer Training Required**      **\#**   **Location & Nature\
                                               of Training**

                                               
  ----------------------------------- -------- -----------------------------

## Post-Delivery Maintenance

*\[Describe maintenance requirements as specified by the customer.\]*

## Customer-Supplied Elements

*\[List any technical and resource-related elements supplied by the
customer that will be used in the production, testing, packaging or
delivery of the product. Do not include funding. Include interfaces,
delivery schedule, medium of supplied items, and the person responsible
on the customer side.\]*

  ----------------------------- ------------------ ------------- ---------------
  **Customer-Supplied           **Medium/Method\   **Delivery\   **Person
  Elements**                    of Delivery**      Schedule**    Responsible**

                                                                 
  ----------------------------- ------------------ ------------- ---------------

## Customer Involvement

*\[Specify how the customer will be expected to take part in the
development process. Typically, the customer will participate in PDT
meetings, technical reviews, and change control boards; will provide
direction, and will witness acceptance tests. There may be other forms
of direct interaction, such as regular status meetings, participation in
working groups, analyst support in software test, etc. Include roles,
responsibilities, authority, and accountability.\]*

## Customer Requirements Review & Update Process

*\[Describe the process used to evaluate and approve changes to the
customer requirements. Be sure to note that the PDT will be evaluating
the changes to assure that they have the capability of providing the
requested changes within the allotted resources and schedule. Approval
authorities (those listed on the signature page) must be specified by
name and title. It must be stated whether or not the approval
authorities consist of the CCB. If the approval authority is the CCB,
then the CCB process and membership must be described or referenced. If
the approval authority is not the CCB, then specify the approval
authority and describe or reference its process and membership. The
original approval authority must also approve any changes.\]*

## Resources Needed

*\[Identify who is responsible for the [official]{.underline} budget for
this software project. In many cases, the budget will reside with the
Mission Project. If so, reference the customer budget documentation.*

*Describe (or reference) the process used to estimate the resource needs
for this project. Include the list the parameters and/or rationale used
to determine what resources are required (e.g., estimates of software
functionality or size, a list of key activities, a list of necessary
facilities and equipment). Specify the project's resource needs as cost
in dollars (\$) and/or effort in full-time equivalents (FTEs) or
staff-years. Budget information should be provided by fiscal quarter,
and must include civil service staffing as well as contractor support.
Address any specific facilities or any facility modifications required
for use in development or testing. Include the following statement:\]*

See Section 3.4 for detailed information concerning resources that will
be procured.

*\[Identify who is responsible for obtaining, monitoring, and
controlling the budget within this software project. Describe the
mechanisms that will be used to resolve budget issues with the Mission
Project.\]*

# Software Management Approach

## General Development Approach

*\[Describe briefly the general philosophy that will be used to build
the product, discussing such aspects as use of COTS, contractor
involvement, schedule constraints, build/release approach, use of a
particular development methodology or new technology, etc.\]*

## Work Breakdown Structure

*\[All project products and services should be developed in the context
of a work breakdown structure (WBS), which forms the basis for work
planning, progress measurement, and reporting. Include a graphical or
tabular representation of the project's WBS. Also include detailed
descriptions of each of the activities in the WBS.\]*

## PDT Information

This section describes the roles, responsibilities and organization of
the development team.

### Product Development Team (PDT) Charter

*\[Include a brief description of what this PDT is being asked to
accomplish, including any time constraints or interface boundaries
within which this PDT is expected to operate.\]*

### Organization

*\[Include a diagram illustrating the organization of the PDT personnel
and its activities. Show the relationship of the Product Development
Lead (PDL) to the higher-level Mission Project organization for status
and accountability, if applicable. Show how QA, CM, and IV&V activities
are organized. The following diagram is provided as an example and
should be modified to fit the project.\]*

### Roles, Responsibilities, Authority, & Accountability

*\[Identify the authority and responsibility of each organizational unit
within the PDT. Reference the Work Breakdown Structure used to assign
work to PDT members. Assignments may be made by subsystem (e.g., Command
& Data Handling, Planning & Scheduling) or by work function (e.g.,
testing). Include work assignments that will result in non-deliverable
products (e.g., test tools) as well as deliverable products and
services. State explicitly whether work assignments will be authorized
using the WOA process (WOA Form 4-30) or whether work assignments are
authorized by this SMP/PP.*

*For each of the following process activities, identify the PDT member
and/or role responsible for the activity: (NOTE: Individuals responsible
for these roles must be identified either in this Plan or in a separate,
referenced document.)\]*

  -----------------------------------------------------------------------
  **Process Activity**       **Responsible Role** **Responsible
                                                  Individual**
  -------------------------- -------------------- -----------------------
  Project Planning           *\[Usually the       
                             PDL\]*               

  Project Monitoring &       *\[Usually the       
  Control                    PDL\]*               

  Risk Management            *\[Usually the       
                             PDL\]*               

  Supplier Agreement                              
  Management (if applicable)                      

  Requirements Development                        

  Requirements Management                         

  Decision Analysis &                             
  Resolution                                      

  Technical Solution (i.e.,                       
  design and implementation)                      

  Product Integration                             

  Verification                                    

  Validation                                      

  Configuration Management   *\[Usually the       
                             CMO\]*               

  Measurement & Analysis                          

  Software Assurance                              

  Training                                        

  Software Process                                
  Improvement                                     

  Software Process                                
  Definition                                      
  -----------------------------------------------------------------------

### Stakeholder Involvement 

*\[Identify other organizations, teams, or groups necessary in
developing, verifying, validating, or using the product. (NOTE: Customer
stakeholders should be identified in Section 2.) Provide a matrix
listing each stakeholder against the activities in which the stakeholder
is involved. (See sample below.) Describe the purpose and rationale for
each stakeholder's involvement, its importance to the project, and the
authority and responsibility of the external stakeholder. Identify who
is responsible on both sides of the interface, i.e., within the PDT and
within the external organization, team, or group. Examples of interface
activities include those of the flight software group to the flight
hardware group for working compatibility issues; those of the Ground
Data System to the Flight Operations Team for acceptance of the system;
those of the PDL to line management, and those of the PDT to Safety and
Mission Assurance, IV&V, and ITA.*

*Describe how stakeholder involvement will be monitored and documented,
e.g., by publishing expected attendees at reviews/walkthroughs and
recording attendance. Identify any additional project effort or
materials needed to ensure that stakeholders become and remain involved
(e.g. briefings to stakeholders, walkthroughs, hardcopies of review
materials).\]*

+--------------------------+----------+----------+----------+----------+
| **PDT Activity**         | ***\[Sta | ***\[Sta | ***\[Sta | ***\[Sta |
|                          | keholder | keholder | keholder | keholder |
|                          | A\]***   | B\]***   | C\]***   | D\]***   |
+--------------------------+----------+----------+----------+----------+
| *\[Name or brief         | *\[Rat   |          | *\[Rat   |          |
| description of activity  | ionale,* |          | ionale,* |          |
| X*\]                     |          |          |          |          |
|                          | *Respons |          | *Respons |          |
|                          | ibility, |          | ibility, |          |
|                          | etc.\]*  |          | etc.\]*  |          |
+--------------------------+----------+----------+----------+----------+
| *\[Name or brief         |          | *\[Rat   |          |          |
| description of activity  |          | ionale,* |          |          |
| Y\]*                     |          |          |          |          |
|                          |          | *Respons |          |          |
|                          |          | ibility, |          |          |
|                          |          | etc.\]*  |          |          |
+--------------------------+----------+----------+----------+----------+
| *\[Name or brief         |          |          |          | *\[Rat   |
| description of activity  |          |          |          | ionale,* |
| Z*\]                     |          |          |          |          |
|                          |          |          |          | *Respons |
|                          |          |          |          | ibility, |
|                          |          |          |          | etc.\]*  |
+--------------------------+----------+----------+----------+----------+

### Training Plan

*\[Identify any required task-specific training needed by PDT members
and when it will be needed (e.g., prior to coding, before the start of
system integration). Required task-specific training is defined as
training that must be taken to acquire new skills or enhance current
skills necessary to the performance of a project role. This includes
familiarizing PDT members with the SMP/PP; the methodology, standards,
and design process used; the team records; the use of a nonconformance
recording system, or training required when working in proximity to
instruments or spacecraft, such as Electrostatic Discharge Awareness
Training, Range or Launch Safety, Laser Safety, etc. Include a statement
that ISD-required training will be expected for all staff with roles in
the PDT and list the roles.*

*Describe your plan for getting each training item to the PDT, i.e., is
the course available in-house or will it be purchased as vendor-supplied
training? If any PDT member will receive training via mentoring,
document how this will be accomplished. When training is complete,
document it by keeping a list of completion dates and attendees for each
course.\]*

## Procurement

*\[Describe (or include by reference) all hardware and software purchase
requirements in detail. Include any purchases necessary for facility
modification. Describe (or reference) the procurement process that will
be followed.*

*If you are using contractor support, describe the contractor selection
process and contractor involvement in the software project. If special
or unusual contracting arrangements are required, describe them. List
the contractor name and contract number. Identify who has authority for
interfacing with the contractor and describe roles and responsibilities
on both sides of the interface. Describe (or reference) the process that
will be used to monitor and control this contractor support.\]*

## Risk Management

*\[If risks are described in a separate Risk Management Plan or within
the Mission Project's Risk Mitigation Document, reference that document
here. If no initial risks can be identified, state that. Otherwise,
include the following information:*

*Identify the risk sources and categories for this project. [Risk
sources]{.underline} are fundamental drivers, either internal or
external, that cause risks within a project. Examples include: uncertain
requirements, a new type of development, a marginal design, new or
unavailable technology, inadequate staffing or skills, and cost or
funding issues. [Risk categories]{.underline} are the "bins" used for
collecting and organizing risks. Examples are: risks by lifecycle phase,
by project management area (cost, schedule, performance, contractor,
etc.), or by product type (e.g., subsystem). Define parameters to
characterize these risks (e.g., severity, likelihood). Characterize each
risk using these parameters.*

*Describe how risks will be continuously identified, analyzed, planned
for, tracked, controlled, communicated, and documented during the
project's life cycle. Risk management must be conducted in accordance
with the NASA process and resources for Continuous Risk Management as
found in NPG 7120.5, "NASA Program and Project Management Processes and
Requirements" and NPR 8000.4, "Risk Management Procedural Requirements.
Both of these documents are located at <http://nodis.hq.nasa.gov/>.\]*

## Software Safety

*\[Describe the procedures for implementing the NASA software safety
standard if any part of the software produced by this project is
identified as safety critical. Include procedures for documenting and
tracing software safety requirements through all software phases,
reporting and resolving discrepancies with safety-critical software, and
verifying and certifying the safety-critical components. See NASA-STD
8719.13B, NASA Software Safety, at
[http://www](http://www/)[.hq.nasa.gov/office/codeq/software/docs.htm]{.underline}.
Also see the NASA Software Safety Guidebook, NASA-GB-8719.13, which is
designed to help create a set of tailored activities and analyses that
will meet the requirements of the Software Safety Standard. Software
safety analysis verifies that the software contains no errors or
deficiencies that could contribute to risks to people or property. If
there is no software produced that is identified as safety critical,
then state that.\]*

## Software Security and Privacy

*\[The software project manager is responsible for requirements
associated with the...*

-   *Security of people and NASA assets,*

-   *Security of information technology,*

-   *Proper export of controlled hardware, technology, and data
    (including software), and*

-   *Involvement of partners, contractors, and citizens of foreign
    countries.*

*If the project has a separate Security Plan, reference it here.
Otherwise, describe the project's plans for addressing security and
privacy considerations, both physically for the facilities involved and
electronically for any computer systems being used either for
development and testing or as a part of the final product. Address each
of the items in the bulleted list above. Also provide input to the
Mission Project Security Plan, as needed to comply with NPR 2810.1,
Security of Information Technology, located at
<http://nodis.hq.nasa.gov/>.\]*

## Independent Verification and Validation (IV&V) 

*\[The PDL shall provide the appropriate documentation and software
information to the Mission Project Manager to assess the IV&V
requirements for the mission. Once the IV&V requirements have been
determined and documented by the Mission Project, the PDL is responsible
for interfacing with the IV&V facility and providing any required
support to the IV&V activity. Identify the IV&V support needed from this
project and describe your plan for providing it.\]*

## Review Program

*\[GPR 8700.4 and GPR 8700.6 define the procedures and guidelines for
required Mission reviews and their applicability. The software PDT
participates in, or contributes material to, required Mission-level
Project or Program reviews (e.g., EPRs or IIRs), as needed. In addition,
the PDL shall define, with the participation of the Product Manager,
line management, the customer, and user groups, an appropriate set of
software reviews as a resource to increase the probability of success.
Describe the types of software reviews you plan to hold and the
membership of the review boards. Software reviews may be combined to
improve value or efficiency. However, when reviews are combined, review
objectives from each shall be addressed to the level of detail required
for the individual reviews.*

*Additional management (e.g., branch-level) reviews should be conducted
for status reporting, staffing, budget review, etc. Describe the
management reviews that are planned, their participants, frequency, and
function.*

*Use Section 4.6 to describe the peer reviews (inspections and
walkthroughs) that are planned for this project. Identify work products
that will be verified by peer review in Section 4.5.1.\]*

## Overall Schedule

*\[Reference (preferred) the overall, detailed schedule used to manage
PDT activities. This schedule should include project planning, facility
preparations, procurements, system development by phase and
build/release, product delivery, software services; maintenance (if
applicable), and process activities (project planning, establishment of
a CM system, software assurance, etc.). Be sure to include schedule
dates for reviews, documentation, delivery of interface control
documents (ICDs), tests, software releases, procurements, and external
deliveries to the customer. Specify the parameters or rationale used as
a basis for the schedule. The detailed schedule should include and be
consistent with any customer-specified schedules for this project, as
defined in Section 2.4. It should also be consistent with the life-cycle
described in Section 4.2.1.\]*

## Status Tracking 

*\[Describe the method(s) that will be used to track status throughout
the life cycle of this project. Methods may include:*

-   *Earned Progress (e.g., Point Counting)*

-   *Schedule charts with status indicated*

-   *Module status checklists*

-   *Test status matrices*

*Identify how frequently status will be updated, when it will be
reported, and who is responsible.\]*

## Data Management (DM)

*\[If there is a separate Data Management Plan for the project,
reference it here. Otherwise, include the following information. See GPR
1440.7, "Records Control," and PAL#3.1.1.2, "ISD Guidance on Data
Management and Process Configuration Management," for further
information.*

*Provide a Master List of ALL project data, such as documents, meeting
minutes, action items, status reports, code, correspondence, etc.
Identify who is responsible for the each data type. Identify when,
where, and how each data type will be collected, stored, distributed,
and archived. Storage might be in a Project Library, PDL notebook, a
project website, a controlled library, etc. If the data item will not be
retained, state that fact. Note any privacy or security requirements on
the data. Ensure this Master List includes project resources needed
(cost and/or effort), schedule, and all related estimates and BOEs.*

*In the DM Master List, also identify the types of documents and data
that will be configuration-controlled and when each type will be placed
under CM. Include the document or database name, the date or version
identification of the current version, the location of the documents or
database, and the person responsible for the item. (NOTE: Any databases
or web sites containing information directly under the PDT's control
should contain a header identifying what is being viewed, as well as the
date of the last change and the person responsible for its control.)\]*

## Project Measures

*\[Based on the project's information needs and goals, identify specific
measurement objectives \-- and the measures that will be collected and
analyzed to satisfy these objectives \-- in each of the following
areas:*

a.  Software progress and cost tracking

b.  Software functionality

c.  Software quality

d.  Software requirements volatility

e.  Software characteristics

*In addition, projects that are required to be CMMI Level 2 must collect
and analyze process measures for each of seven process areas: Project
Planning, Project Monitoring and Control, Configuration Management,
Requirements Management, Process and Product Quality Assurance,
Measurement and Analysis, Verification, and Validation.*

*Table 3.13 lists the recommended measures for ISD Class B and C
projects. Additional measurement guidance is provided at
<http://software.gsfc.nasa.gov/metrics.htm>.\]*

Table 3.13: Recommended Project Measures

+----------+-----------------+------------+---------------------------+
| **Mea    | **Measurement   | **         | **Measure(s)**            |
| surement | Objective**     | Analysis** |                           |
| Area**   |                 |            | **(Asterisk (\*)          |
|          | *\[Sample       |            | indicates measure is      |
|          | objectives are  |            | required by the ISD       |
|          | listed          |            | Measurement Program.)**   |
|          | below.\]*       |            |                           |
+----------+-----------------+------------+---------------------------+
| Software | Ensure project  | Compare    | \*Event dates (planned    |
| progress | schedule is     | planned    | and actual)               |
| and cost | within 10% of   | vs. actual |                           |
| tracking | the planned     | schedule;  | (NOTE: Collect both       |
|          | schedule.       | analyze    | milestone dates and       |
|          |                 | d          | process event dates.)     |
|          |                 | eviations. |                           |
+----------+-----------------+------------+---------------------------+
|          | Ensure product  | Compare    | \*Progress tracking       |
|          | progress is     | planned    | points (planned and       |
|          | within 10% of   | progress   | actual)                   |
|          | planned         | points vs. |                           |
|          | progress.       | actual     |                           |
|          |                 | progress   |                           |
|          |                 | points.    |                           |
+----------+-----------------+------------+---------------------------+
|          | Ensure project  | Compare    | a.  \*Total Effort        |
|          | effort and      | planned    |     (planned and actual   |
|          | costs remain    | vs. actual |     FTEs for civil        |
|          | within 10% of   | effort.    |     servants and          |
|          | budget.         |            |     contractors)          |
+----------+-----------------+------------+---------------------------+
|          |                 | Compare    | b.  Effort by CSCI        |
|          |                 | planned    |     (planned and actual)  |
|          |                 | vs. actual |                           |
|          |                 | costs.     | c.  Facility and          |
|          |                 |            |     equipment costs       |
|          |                 |            |     (planned and actual)  |
+----------+-----------------+------------+---------------------------+
| Software | Deliver the     | Compare    | Number of requirements in |
| funct    | required        | planned    | the release/build         |
| ionality | software        | vs.        | (planned and delivered)   |
|          | functionality.  | delivered  |                           |
|          |                 | by release |                           |
|          |                 | or build.  |                           |
+----------+-----------------+------------+---------------------------+
|          | Ensure          | Compare    | Memory utilization or     |
|          | performance     | critical   | timing by CSCI (planned   |
|          | measures are    | p          | and actual)               |
|          | within margins. | erformance |                           |
|          |                 | measures   |                           |
|          |                 | against    |                           |
|          |                 | margins.   |                           |
+----------+-----------------+------------+---------------------------+
| Software | Ensure product  | Compare    | a)  \*Number of defects   |
| quality  | quality.        | expected   |     by severity           |
|          |                 | vs. actual |     (critical, moderate,  |
|          |                 | level of   |     minor)                |
|          |                 | defects.   |                           |
+----------+-----------------+------------+---------------------------+
|          |                 | Analyze    | b)  Open and closed       |
|          |                 | resp       |     defects by severity   |
|          |                 | onsiveness |                           |
|          |                 | to         | c)  Length of time        |
|          |                 | detected   |     defects open by       |
|          |                 | defects.   |     severity              |
+----------+-----------------+------------+---------------------------+
|          |                 | Analyze    | Open and closed RFAs by   |
|          |                 | resp       | length of time open       |
|          |                 | onsiveness |                           |
|          |                 | to action  |                           |
|          |                 | items.     |                           |
+----------+-----------------+------------+---------------------------+

Table 3.13: Recommended Project Measures (continued)

+----------+-----------------+------------+---------------------------+
| **Mea    | **Measurement   | **         | **Measure(s)**            |
| surement | Objective**     | Analysis** |                           |
| Area**   |                 |            | **(Asterisk (\*)          |
|          | *\[Sample       |            | indicates measure is      |
|          | objectives are  |            | required by the ISD       |
|          | listed          |            | Measurement Program.)**   |
|          | below.\]*       |            |                           |
+----------+-----------------+------------+---------------------------+
| Software | Control         | Compare    | a)  \*Total number of     |
| requ     | requirements    | actual to  |     (actual) requirements |
| irements | volatility.     | expected   |     changes (i.e., sum of |
| vo       |                 | level of   |     additions, changes,   |
| latility |                 | re         |     and deletions)        |
|          |                 | quirements |                           |
|          |                 | changes.   | b)  Requirements changes  |
|          |                 |            |     by CSCI               |
+----------+-----------------+------------+---------------------------+
|          |                 | Compare    | c)  \*Total number of     |
|          |                 | actual to  |     (actual) requirements |
|          |                 | expected   |     TBDs                  |
|          |                 | level of   |                           |
|          |                 | re         | d)  Requirements TBDs by  |
|          |                 | quirements |     CSCI                  |
|          |                 | TBDs.      |                           |
+----------+-----------------+------------+---------------------------+
| Project  | Ensure project  | R          | e)  \*Original and        |
| Planning | is re-planned   | e-estimate |     revised planning      |
|          | if current      | planning   |     parameters (cost,     |
|          | estimates       | parameters |     effort, schedule,     |
|          | exceed planning | and        |     local size measure)   |
|          | parameters by   | compare to |     by revision           |
|          | 20%.            | current    |                           |
|          |                 | estimates. | f)  Number of revisions   |
|          |                 |            |     to plan               |
+----------+-----------------+------------+---------------------------+
| Project  | Ensure          | Analyze    | Number of open vs. closed |
| Mo       | necessary       | resp       | action items              |
| nitoring | project         | onsiveness |                           |
| and      | activities are  | to action  |                           |
| Control  | performed.      | items      |                           |
+----------+-----------------+------------+---------------------------+
|          | Ensure project  | Analyze    | Milestone dates met vs.   |
|          | schedules are   | o          | missed                    |
|          | met.            | ccurrences |                           |
|          |                 | and trend. |                           |
+----------+-----------------+------------+---------------------------+
|          | Ensure project  | Analyze    | Number of added,          |
|          | risks are       | changes to | modified, and retired     |
|          | monitored and   | risk       | risks by severity         |
|          | controlled.     | parameters |                           |
|          |                 | and        |                           |
|          |                 | p          |                           |
|          |                 | riorities. |                           |
+----------+-----------------+------------+---------------------------+
| Confi    | Ensure          | Compare    | Number of changes to      |
| guration | configuration   | number of  | configured items          |
| Ma       | management is   | changes to |                           |
| nagement | being performed | expected   |                           |
|          | as planned.     | levels.    |                           |
+----------+-----------------+------------+---------------------------+
|          |                 | Compare    | Effort expended in        |
|          |                 | planned    | configuration management  |
|          |                 | vs. actual | (planned and actual)      |
|          |                 | effort.    |                           |
+----------+-----------------+------------+---------------------------+
| Requ     | Ensure          | Compare    | Number of additions,      |
| irements | requirements    | re         | changes, deletions to     |
| Ma       | are being       | quirements | requirements by CSCI      |
| nagement | managed as      | changes to |                           |
|          | planned.        | expected   |                           |
|          |                 | levels.    |                           |
+----------+-----------------+------------+---------------------------+
| Process  | Ensure software | Compare    | Number of evaluations     |
| and      | assurance is    | planned    | (planned and actual)      |
| Product  | being performed | vs. actual |                           |
| Quality  | as planned.     | ev         |                           |
| A        |                 | aluations. |                           |
| ssurance |                 |            |                           |
+----------+-----------------+------------+---------------------------+
| Mea      | Ensure project  | (as listed | (as listed in this table) |
| surement | measures are    | in this    |                           |
| and      | collected and   | table)     |                           |
| Analysis | analyzed as     |            |                           |
|          | planned.        |            |                           |
+----------+-----------------+------------+---------------------------+

Table 3.13: Recommended Project Measures (continued)

+----------+-----------------+------------+---------------------------+
| **Mea    | **Measurement   | **         | **Measure(s)**            |
| surement | Objective**     | Analysis** |                           |
| Area**   |                 |            | **(Asterisk (\*)          |
|          | *\[Sample       |            | indicates measure is      |
|          | objectives are  |            | required by the ISD       |
|          | listed          |            | Measurement Program.)**   |
|          | below.\]*       |            |                           |
+----------+-----------------+------------+---------------------------+
| Veri     | Ensure          | Compare    | Number of peer reviews    |
| fication | verification    | planned    | (planned and performed)   |
|          | activities are  | vs. actual |                           |
|          | performed as    | numbers of |                           |
|          | planned.        | peer       |                           |
|          |                 | reviews.   |                           |
+----------+-----------------+------------+---------------------------+
|          |                 | Compare    | Time spent on peer        |
|          |                 | actual vs. | reviews (preparation and  |
|          |                 | planned    | review)                   |
|          |                 | effort on  |                           |
|          |                 | peer       |                           |
|          |                 | reviews.   |                           |
+----------+-----------------+------------+---------------------------+
|          |                 | Compare    | Number of defects found   |
|          |                 | numbers of | (in peer reviews) by type |
|          |                 | defects    |                           |
|          |                 | found to   |                           |
|          |                 | expected   |                           |
|          |                 | levels.    |                           |
+----------+-----------------+------------+---------------------------+
| Va       | Ensure          | Compare    | Number of validation      |
| lidation | validation      | number of  | events (planned and       |
|          | activities are  | planned    | completed)                |
|          | performed as    | vs.        |                           |
|          | planned.        | completed  |                           |
|          |                 | validation |                           |
|          |                 | events.    |                           |
+----------+-----------------+------------+---------------------------+
| Software | Support ISD     | (None      | a)  \*Software project    |
| charact  | model-building  | required   |     name                  |
| eristics | for future      | at the     |                           |
|          | process         | project    | b)  \*Software domain     |
|          | improvement.    | level.)    |     (flight, ground,      |
|          |                 |            |     analysis/research,    |
|          |                 |            |     infrastructure,       |
|          |                 |            |     other)                |
|          |                 |            |                           |
|          |                 |            | For each CSCI:            |
|          |                 |            |                           |
|          |                 |            | c)  \*CSCI name           |
|          |                 |            |                           |
|          |                 |            | d)  \*CSCI Type (e.g.,    |
|          |                 |            |     for FSW: C&DH, ACS,   |
|          |                 |            |     Science; for Ground:  |
|          |                 |            |     T&C, FDS, P&S,        |
|          |                 |            |     Science Lvl 0)        |
|          |                 |            |                           |
|          |                 |            | e)  \*Primary language    |
|          |                 |            |     (e.g., C, C++)        |
|          |                 |            |                           |
|          |                 |            | f)  \*COTS/GOTS/MOTS      |
|          |                 |            |     products              |
|          |                 |            |                           |
|          |                 |            | g)  \*Target hardware     |
|          |                 |            |     (e.g., PowerPC)       |
|          |                 |            |                           |
|          |                 |            | h)  \*Operating System    |
|          |                 |            |                           |
|          |                 |            | i)  \*Size (final)        |
|          |                 |            |                           |
|          |                 |            | j)  \*Units (in which     |
|          |                 |            |     size is measured)     |
+----------+-----------------+------------+---------------------------+

*Describe or reference the approach that will be used to collect, store,
analyze, and report the project measures. Include information such as
the formats/units in which the measures will be collected (e.g., SLOC);
how the measures will be collected, by whom and when; where the data
will be stored, who controls it, and how long it will be retained; how
the data will be analyzed, by whom, and how often; and how the analysis
results will be reported, to whom and how often. If any of this
information is unique to specific measures, consider adding one or more
columns to Table 3.13 to describe the details of the approach on a per
measurement basis.*

## Key Issues, Decisions, and Rationale 

The PDL will maintain a log of the PDT's key issues, decisions, and
rationale throughout the life cycle of the project. *\[Reference the DM
Master List, which must identify where, how, and when this log will be
maintained. See Section 3.12.\]*

## Lessons Learned

*\[Describe the process to be followed to ensure capture by the PDT of
relevant lessons learned throughout the project's life cycle. Use or
modify the following process steps:\]*

-   The PDL will query the NASA Lessons Learned Information System
    (LLIS, which is maintained at
    [http://llis.nasa.gov](http://llis.nasa.gov/) ) and other knowledge
    resources at the beginning of each phase of the software development
    lifecycle to access relevant past experiences and knowledge that can
    be leveraged to reduce risk, improve quality and efficiency.

-   The PDL will consider any significant lessons learned for inclusion
    in LLIS and submit those lessons, if appropriate.\]

-   The PDL will document final lessons learned and submit them to the
    GSFC EPG via
    [http://software.gsfc.nasa.gov](http://software.gsfc.nasa.gov/).
    These lessons learned should summarize the PDT's key recommendations
    for improving the development/maintenance process in future similar
    projects.

# Software Technical Approach

##  {#section .unnumbered}

## Derived Requirements

*\[Reference (preferred) or describe the requirements and/or
specifications derived from customer requirements by the PDT and
approved by the Customer, PDL and appropriate manager. These should
include assumptions, interfaces, and performance information. Ensure
that requirements are testable. Highlight requirements that will drive
software design decisions, e.g., special timing requirements or
checkpoint restart. If no additional requirements/specifications can be
derived, just reference Section 2.3. Reference or describe the process
used to validate these requirements.\]*

## Development Strategy

### Development Life-Cycle

*\[Discuss the life-cycle model that will be used (e.g., waterfall,
spiral model, iterative development) and briefly describe how the model
has been tailored for this project. Provide a diagram of, or otherwise
describe, this tailored life-cycle. Include each life-cycle phase, the
activities to be performed in each phase, the major products of the
phase, and the "gates" (e.g., reviews or other milestones) that must be
passed before the next phase or major activity can begin.\]*

### Development Process

*\[Reference (preferred) or describe at a high level the development
processes and procedures the PDT will use, including those for software
integration and software/hardware integration.*

*The GSFC Process Asset Library at
[http://software.gsfc.nasa.gov](http://software.gsfc.nasa.gov/) is the
repository for standard ISD and Branch-tailored processes and
procedures. Tailoring of these processes and procedures is determined by
the PDL with the concurrence of line management and the customer
(typically a project manager or principal investigator). Tailoring
factors include project characteristics such as the criticality of the
application, the size of the PDT and user community, the degree of
reuse, and other project specific factors.\]*

### Development Environment

*\[Describe the development and test facilities, equipment, libraries,
and tools. Include descriptions of each software verification
environment that is to be established for the project, e.g., software
testing environment, system testing environment, regression testing
environment. Also include descriptions of each software validation
environment, e.g., simulators for the operational environment,
acceptance testing environment. Describe plans (such as back-ups) to
prevent loss or damage to all of the products (including software,
documentation and hardware) during all phases of development.\]*

### Make/Buy Approach 

*\[Identify which make/buy decisions will be made using a formal
decision analysis process, such as a trade-study, that evaluates
identified alternatives against established criteria. Reference
(preferred) or describe any special purchasing strategies for items
specified in Section 3.4. This may include strategies for use of COTS
such as agreements for vendor modifications to address specific
requirements. ( See GPR 5100.1 for additional information on
procurements.)\]*

### Customer-Supplied Products Approach

*\[Briefly describe the approach that will be used to integrate any
customer-supplied items (as specified in Section 2.9) required for the
development and test of final product. Identify any assumptions
concerning these items or their integration.\]*

### Rights and Approvals

*\[If new technology, open source software or commercial, government, or
modified off-the-shelf software (COTS, GOTS, MOTS) is to be incorporated
in the delivered software system, identify any approvals required for
proprietary, usage, ownership, warranty, and licensing rights. Open
source software licenses should be reviewed by the Center Chief of
Patent/Intellectual Property Counsel before being accepted into software
development projects. Identify any other regulated approvals or required
certifications for system components.\]*

### Prototyping Approach

*\[Describe any prototyping activities required to develop the product
and the purpose of the prototype (i.e., "What specific questions are to
be answered by the prototype?"). If the criteria to be used in
evaluating the prototype are known, identify them here. Otherwise,
itemize these criteria in the prototype's documentation.\]*

## Product Design

*\[Reference (preferred) or briefly describe the design of the product
the PDT is planning to produce. Describe how changes in design are
incorporated and traced to changes in the requirements. Describe how the
design will be traced to the customer-specified and derived
requirements/specifications, (Sections 2.3 and 4.1, respectively). \]*

## Build Approach

*Briefly describe your build approach, including:*

-   *the development phases*

-   *the sequence of versions/releases*

-   *vendor/customer/ prototype elements to be integrated*

-   *the requirements satisfied in each version/release*

    *If a separate Build/Release Plan will be produced, reference it
    here.\]*

## Verification and Validation

### Product Verification

*\[Verification confirms that work products properly reflect the
requirements specified for them. Identify the software verification
procedures and criteria that will be used across the project's life
cycle, e.g., peer reviews, inspections, re-inspection criteria, testing.
List the work products that will be verified using these procedures and
criteria (e.g., peer reviews or inspections of code; tests of code
against requirements and design). Include peer reviews of software
requirements and test plans in this list.*

*Describe the testing approach from unit testing through product
delivery, including in-process and final inspection. Reference your test
plans and discuss your testing approach for unit, build/release, and
system testing; the composition of the test team (developers,
independent, customer); the test environment; test data (simulator,
supplied data, flight hardware, real data); and any related success
criteria (particularly any from the customer for final acceptance---see
Section 2.6) Describe how changes in requirements and design are mapped
to changes in test plans.*

*Identify where the actual software verification records (e.g., peer
review records, inspection records, test records) and analyses of
results will be documented. Identify where software verification
corrective actions will be documented. Describe the corrective-action
procedures themselves in Section 5.2.\]*

### Statistical Techniques 

*\[Unless the PDT determines a need for statistical testing of the
product or other statistical methods, include the following paragraph in
this section.\]*

The PDT evaluated the need for statistical testing of the products
developed under this SMP/PP and determined that statistical techniques
are not required.

*\[Examples of statistical techniques being used are (1) techniques to
obtain reliability of hardware systems and (2) comparisons of output
results after a platform language conversion. If statistical techniques
are being used, then the procedure for their use must be documented.\]*

### Incoming Inspection and Test 

*\[For purchased items, including hardware and flight-critical
components, document the Receiving Inspection Instructions to describe
special receiving instructions and tests other than kind, count and
condition.\]*

### Product Validation 

*\[Validation demonstrates that a software product or product component
fulfills its intended use in its operational environment. Validation
activities are performed on work products in every phase of the life
cycle. For example, requirements validation might be performed via the
SRR; a software design might be validated by a prototype demonstration.
Methods of software validation include acceptance testing on the
targeted platform, high-fidelity simulation, analysis against
mathematical models, and operational demonstrations.*

*Identify the validation procedures and criteria that will be used
across the project life cycle. List the work products that will be
validated using these procedures and criteria, e.g., user groups
reviewing requirements and prototypes, acceptance testing of each
software release, operational demonstrations of the software product.*

*Identify where the actual software validation records (e.g., user group
review records, prototyping records, acceptance test records) and
analyses of results will be documented. Identify where software
validation corrective actions will be documented. Describe corrective
action procedures in Section 5.2.\]*

## Peer Review/Inspection Process

*\[Peer reviews and inspections are the in-process technical examination
of work products by the supplier's peers for the purpose of finding and
eliminating defects early in the life cycle. Reference (preferred) or
describe the procedures the PDT will follow to prepare for and conduct
peer reviews/inspections, to document results, and to certify
completion. Include in these procedures the use of checklists to
evaluate the work products, the use of readiness and completion
criteria, the tracking and closure of action items, and the recording of
basic measurements for the review. Describe your plan for analyzing
measurements and results from multiple peer reviews in order to identify
systemic problems and to improve the peer review process.\]*

## Documentation

*\[Provide a documentation tree that lists, in hierarchical format, all
controlled documents the PDT will produce throughout the project's life
cycle. Include the SMP/PP and its subsidiary documents and plans, e.g.,
the Software Configuration Management Plan, Software Assurance Plan, and
Software Maintenance Plan. Include all requirements documents, design
descriptions, and user guides. Include the Software Test Plan and its
component Software Test Procedures and Software Test Reports. See
Chapter 5 of NPR 7150.2 for a list of project documents and document
contents. Describe the contents of listed documents or state that they
will conform to NPR Chapter 5.\]*

## Product Delivery 

*\[Reference or describe the process/procedure that will be used for
product delivery. List the media and methods by which the various
products are to be delivered to the customer. (Media/methods specified
by the customer should be listed in Section 2.5.) State that products
released to the customer will include a Product Release Letter listing
the release number, the included capabilities of the release, and a
description of any remaining nonconformances in the release.\]*

## Product Maintenance

*\[Reference the Software Maintenance Management Plan (SMMP) or describe
the process for post-delivery product maintenance, including processes
for maintenance specified by the customer in Section 2.8 and any derived
maintenance requirements (i.e., "How do you plan to meet the
requirements specified in Section 2.8?"). Address responsibility for the
maintenance. Describe the processes that will be used for handling
maintenance requests, for doing work, and for product redelivery of
custom, GOTS and COTS software, and hardware.\]*

# Product Control and Assurance

## Configuration Management (CM) 

*Describe how the PDT will manage the project's software, hardware, and
documentation configurations and who has the change authority for each.
Include identification of any CCBs and the items controlled or reference
the Master List of project data (Section 3.12). If you use the Mission
Project's configuration management process for any of these items,
specify where Project procedures can be found. Describe the method used
to uniquely identify versions of the software and the elements from
which it is built. If on-line copies of documentation or software are
considered the controlled copy, then the approval authority should
control on-line change access. (NOTE: Identify CM procedures for test
hardware and software in Section 5.3. Describe CM procedures for
customer-supplied elements in Section 5.4.)*

## Control of Nonconforming Products and Corrective Action 

*\[Describe the criteria and process for recording and correcting
problems in a "minor" Nonconformance Reporting/Corrective Action
(NCR/CA) system (e.g., a discrepancy/change reporting system). Include a
description of the process used to evaluate the cause of the problem and
to assess whether any changes need to be implemented to prevent future
recurrences. The minor NCR system should include the version or release
number where the problem was found and, ideally, the version number that
includes the corrections. Any nonconforming products released to the
customer shall be identified as such in the release letter, which shall
describe the remaining nonconformance. The release number and the list
of NCR's associated with the release identify Nonconforming products.
Products with remaining nonconformance may only be released to the
customer with proper approval. (After product delivery the Center NCR/CA
system shall be used if no minor nonconformance system exists or if the
nonconformance meets the criteria for a major nonconformance as
specified in GPR 1710.1 for use of the Center NCR/CA system.)\]*

## Control of Test Software and Hardware 

*\[Describe anything (hardware and/or software) used to test the
product. Describe how test software will be validated (i.e., how do you
convince yourself that the simulator is working properly?). If the
software used for testing is not the final validation, but is only used
as part of a self-check, where neither the test software nor the product
being tested is considered correct until the final results are correct,
then describe that test capability and any associated limitations.
Describe or reference the configuration management process used to
ensure the appropriate version of the test hardware/software is used.
Also discuss any inspection, measuring, and test equipment (IMTE) being
used and any calibration requirements.\]*

## Control of Customer Supplied Products 

*\[Describe the method that will be used to check out or test the
software or hardware supplied to you by the customer for inclusion into
the product or for testing or packaging of the product. If a customer
provides items for use by the PDT in the development/testing of the
product, describe the process used to report any problems with the
item(s) back to the customer. Describe the configuration management
process for changes (initiated by the customer or the PDT) to
customer-supplied elements listed in Section 2.9.*

*Include any other processes used to safeguard customer-supplied
products. This section should address simulators, test data, software
algorithms, software and/or hardware received from the customer.\]*

## Software Quality Assurance

*\[Reference the project's Software Assurance Plan or describe the
overall approach, criteria, and process for software quality assurance.
Describe the interface and communication path between the project and
the external organization providing software quality support. Specific
project characteristics and risks influence quality assurance, and
assurance planning should be tailored to reflect this fact. How will
product evaluation and process monitoring be accomplished? What level of
support will the project have from the center Software Assurance
organization, Code 300?*

*Characteristics that should be considered include safety and mission
criticality of the software, schedule and budget, size and complexity of
the product to be produced, and size and organizational complexity of
the development staff. Consider documentation standards, design
standards, and code standards as well for inclusion in project
standards.*

*For additional information, see the NASA Software Assurance Standard,
NASA-STD-8739.8, and the NASA Software Assurance Guidebook. Both of
these documents can be found at
<http://www.hq.nasa.gov/office/codeq/software/docs.htm>.\]*

# Appendix A: Acronyms {#appendix-a-acronyms .unnumbered}

*\[Include in this appendix all acronyms used in the SMP/PP. Following
is the recommended format and an example of an acronym list.\]*

  ----------- -----------------------------------------------------------
  ARM         Automated Requirements Measurement

  ATRR        Acceptance Test Readiness Review

  BOE         Basis of Estimate

  CCB         Configuration Control Board

  CDR         Critical Design Review

  CM          Configuration Management

  CMMI        Capability Maturity Model^®^ Integration

  CMO         Configuration Management Officer

  COTS        Commercial off the Shelf

  CSCI        Computer Software Configuration Item

  DCR         Discrepancy or Change Request

  DM          Data Management

  EPG         Engineering Process Group

  EPR         Engineering Peer Review

  FTE         Full-Time Equivalent

  GOTS        Government off-the-Shelf

  GPR         Goddard Procedural Requirements

  GSFC        Goddard Space Flight Center

  HCI         Human Computer Interface

  ICD         Interface Control Document

  IIR         Integrated Independent Review

  IMTE        Inspection, Measuring and Test Equipment

  ISD         Information Systems Division

  ISO         International Standards Organization

  ITA         Independent Technical Authority

  IV&V        Independent Verification and Validation

  LLIS        Lessons Learned Information System

  MOTS        Modified off-the-Shelf

  NASA        National Aeronautics and Space Administration

  NCR         Nonconformance Reports

  NCR/CA      Nonconformance Reporting/Corrective Action

  NPD         NASA Policy Directive

  NPG         NASA Procedures and Guidelines

  NPR         NASA Procedural Requirements

  ORR         Operational Readiness Review

  PDL         Product Development Lead

  PDR         Preliminary Design Review

  PDT         Product Development Team

  PM          Product Manager

  PML         Product Maintenance Lead

  PMT         Product Maintenance Team

  QA          Quality Assurance

  QMS         Quality Management System

  RFA         Request for action

  SCR         System Concept Review

  SLOC        Source lines of code

  SMP/PP      Software Management Plan/Product Plan

  SMMP        Software Maintenance Management Plan

  SRR         System Requirements Review

  SSR         Software Specifications Review

  STD         Standard

  TBD         To be determined

  URL         Uniform Resource Locator

  WBS         Work breakdown structure

  WOA         Work order authorization
  ----------- -----------------------------------------------------------

# Appendix B: System/Subsystem Classifications {#appendix-b-systemsubsystem-classifications .unnumbered}

*\[Identify the classification of the overall software system in
accordance with the software classification definitions for Class B and
C software in Appendix B of NPR 7150.2. List the subsystems that
comprise the system and identify the software classifications of each.
Uniquely identify/highlight any subsystems containing safety-critical
software.\]*

  ---------------- ------------------------- ------------- ------------------------
  ***Software      ***Subsystem Name***      ***Class      ***Safety-Critical?***
  System***                                  (A-H)***      

                                                           *\[Y/N\]*

                                                           

                                                           

                                                           
  ---------------- ------------------------- ------------- ------------------------

# Appendix C: Tailoring Matrix for Compliance with  {#appendix-c-tailoring-matrix-for-compliance-with .unnumbered}

# NPR 7150.2 {#npr-7150.2 .unnumbered}

*\[This appendix contains the project's compliance matrix against the
numbered, project-level software engineering (SWE) requirements in NPR
7150.2, including those requirements delegated to other parties or
accomplished by contract vehicles. Compliance is marked with an "X" in
the appropriate Class B and C columns, as shown in Appendix D of NPR
7150.2. Columns should be added for any software in Classes D to H.*

*If the software project has any variants, waivers, or exceptions to the
requirements specified in NPR 7150.2, identify these in the right-hand
column. These tailoring variations must be approved by the designated
ITA. If a requirement may be met by following a Center-defined process
(indicated by "P(Center,)" the applicable GSFC/ISD process asset has
been identified.\]*

***\[This version of the project's compliance matrix is derived from the
September 2004 version of NPR 7150.2. Please make changes to this matrix
as needed to comply with the latest version of Appendix D of NPR
7150.2.\]***

  ------------------------------------------------------------------------------------------------------
  Section of NPR     **Requirement    **SWE     **Class   **Class C**   **Class     **Tailoring
                     Descriptor**     Rqmt.**   B**                     *\[y\]***   Variants, Waivers or
                                                                                    Exceptions**
  ------------------ ---------------- --------- --------- ------------- ----------- --------------------
  **Preface**        Effective Date   1         **X**     **X**                     

                     SW Disclosures   7         **X**     **X**                     

  **Compliance**     Export Control   8         **X**     **X**                     

  **with Laws,**     External Release 9         **X**     **X**                     

  **Policies, &**    Security         10        **X**     **X**                     

  **Requirements**   Disabilities     11        **X**     **X**                     

                     Disabilities     12        **X**     **X**                     

                     SW Plan          13        **X**     **X**                     

                     Execute Plan     14        **X**     **X**                     

                     Cost Estimation  15        **X**     **X**                     

                     Schedule         16        **X**     **X**                     

                     Training         17        **X**     **X**                     

                     Reviews          18        **X**     **X**                     

  **SW Life Cycle**  Life Cycle       19        **X**     **X**                     

  **Planning**       SW               20        **X**     **X**                     
                     Classification                                                 

                     SW               21        **X**     **X**                     
                     Classification                                                 
                     changes                                                        

                     SW Assurance     22        **X\***   **P                       As defined in this
                                                          (project)**               SMP/PP.

                     SW Safety        23        **X**     **X**                     

                     Plan Tracking    24        **X**     **X**                     

                     Corrective       25        **X**     **X**                     
                     Action                                                         

                     Changes          26        **X**     **X**                     

  **Off-the-Shelf    COTS, GOTS, MOTS 27        **X**     **X**                     
  (OTS) SW**                                                                        
  ------------------------------------------------------------------------------------------------------

\* This requirement can only be waived by the OSMA ITA.

  ------------------------------------------------------------------------------------------------------
  Section of NPR     **Requirement    **SWE     **Class B** **Class C**  **Class     **Tailoring
                     Descriptor**     Rqmt.**                            *\[y\]***   Variants, Waivers,
                                                                                     or Exceptions**
  ------------------ ---------------- --------- ----------- ------------ ----------- -------------------
                     Verification     28        **X**       **X**                    
                     planning                                                        

  **Verification &** Validation       29        **X**       **X**                    
                     planning                                                        

  **Validation**     Verification     30        **X**       **X**                    
                     results                                                         

                     Validation       31        **X**       **X**                    
                     results                                                         

                     CMM L3 or CMMI   32        **X\*\***   **P                      
                     L2                                     (Center)**               

                     Options for      33        **X**       **X**                    
                     Acquisitions                                                    

  **Project**        Acceptance       34        **X**       **X**                    
                     Criteria                                                        

  **Formulation**    Supplier         35        **X**       **X**                    
                     Selection                                                       

                     SW processes &   36        **X**       **X**                    
                     tasks                                                           

                     Milestone        37        **X**       **X**                    

                     Acquisition      38        **X**       **X**                    
                     planning                                                        

                     Insight into     39        **X**       **P                      GPR 5100.1,
                     test                                   (Center)**               "Procurement"

  **Government**     Electronic       40        **X**       **P                      GPR 5100.1,
                     access                                 (Center)**               "Procurement"

  **Insight**        Open source      41        **X**       **P                      GPR 5100.1,
                                                            (Center)**               "Procurement"

                     Source code      42        **X**       **P                      GPR 5100.1,
                     access                                 (Center)**               "Procurement"

                     Track change     43        **X**       **P                      GPR 5100.1,
                     request                                (Center)**               "Procurement"

                     SW measurement   44        **X**       **X**                    
                     data                                                            

  **Supplier**       Joint audits     45        **X**       **X**                    

  **Monitoring**     SW schedule      46        **X**       **X**                    

                     Traceability     47        **X**       **P                      GPR 5100.1,
                     data                                   (Center)**               "Procurement"

                     Solicitation     48        **X**       **X**                    

  **SW**             Document         49        **X**       **X**                    

  **Requirements**   SW requirements  50        **X**       **X**                    

  **Development**    Flow-down &      51        **X**       **X**                    
                     derived req.                                                    

                     Bi-directional   52        **X**                                
                     trace                                                           

  **SW**             Manage req.      53        **X**       **X**                    
                     change                                                          

  **Requirements**   Corrective       54        **X**                                
                     action                                                          

  **Management**     Requirements     55        **X**       **X**                    
                     Validation                                                      
  ------------------------------------------------------------------------------------------------------

\*\* For Class B software, in lieu of a CMM/CMMI certification, the
project will conduct an independent software capability evaluation in
the seven process areas listed in SWE-32 and mitigate any risk, if
deficient.

  --------------------------------------------------------------------------------------------------------
  **Section of NPR**    **Requirement    **SWE     **Class   **Class C**  **Class     **Tailoring
                        Descriptor**     Rqmt.**   B**                    *\[y\]***   Variants, Waivers,
                                                                                      or Exceptions**
  --------------------- ---------------- --------- --------- ------------ ----------- --------------------
                        Document design  56        **X**     **P                      GPR 8700.5,
                                                             (Center)**               "In-House
                                                                                      Development &
                                                                                      Maintenance of
                                                                                      Software Products"

  **SW Design**         Architecture     57        **X**     **P                      GPR 8700.5
                                                             (Center)**               

                        Detailed design  58        **X**                              

                        Bi-directional   59        **X**                              
                        trace                                                         

                        Design  code    60        **X**     **X**                    

  **SW**                Coding standards 61        **X**                              

  **Implementa-tion**   Unit test        62        **X**     **X**                    

                        Version          63        **X**     **P                      PAL \# 2.6.1.3, "ISD
                        description                          (Center)**               Product Release
                                                                                      Letter"

                        Maintain         64        **X**                              
                        traceability                                                  

                        Plan,            65        **X**     **X**                    
                        procedures,                                                   
                        reports                                                       

                        Perform testing  66        **X**     **X**                    

                        Test for         67        **X**     **X**                    
                        compliance                                                    

                        Evaluate test    68        **X**     **X**                    
                        results                                                       

  **SW Testing**        Doc. defect &    69        **X**     **X**                    
                        track                                                         

                        Models,          70        **X**                              
                        simulations,                                                  
                        tools                                                         

                        Update plans &   71        **X**     **X**                    
                        procedure                                                     

                        Maintain         72        **X**     **X**                    
                        traceability                                                  

                        Platform or      73        **X**     **X**                    
                        hi-fidelity                                                   
                        simulation                                                    

                        Document         74        **X**     **X**                    
                        Maintenance                                                   
                        plans                                                         

  **SW Operations**     Plan ops, Maint. 75        **X**     **X**                    
                        & Retirement                                                  

  **Maintenance,**      Implement plans  76        **X**     **X**                    

  **& Retirement**      Deliver software 77        **X**     **X**                    
                        product                                                       

                        As-built         78        **X**                              
                        documentation                                                 

                        Develop CM plan  79        **X**     **X**                    

                        Track & evaluate 80        **X**     **X**                    
                        changes                                                       

  **SW**                Identify SW      81        **X**     **X**                    
                        configuration                                                 
                        items                                                         

  **Configuration**     Authorizing      82        **X**                              
                        changes                                                       

  **Management**        Maintain records 83        **X**     **X**                    

                        Configuration    84        **X**                              
                        audits                                                        

                        Implement        85        **X**     **X**                    
                        procedures                                                    
  --------------------------------------------------------------------------------------------------------

  ------------------------------------------------------------------------------------------------------
  **Section of NPR** **Requirement   **SWE    **Class B**  **Class C**  **Class     **Tailoring
                     Descriptor**    Rqmt**                             *\[y\]***   Variants, Waivers,
                                                                                    or Exceptions**
  ------------------ --------------- -------- ------------ ------------ ----------- --------------------
  **Risk             Continuous Risk 86       **X**                                 
  Management**       Management                                                     

                     Requirements &  87       **X**        **P                      
                     Test plan                             (Center)**               

  **Peer Reviews**   Checklist,      88       **X**        **P                      
                     criteria, &                           (Center)**               
                     tracking                                                       

                     Basic measures  89       **X**                                 

                     Objectives      90       **X**        **X**                    

  **SW**             SW measurement  91       **X**        **P                      
                     areas                                 (Center)**               

  **Measurement**    Collection &    92       **X**        **X**                    
                     storage                                                        

                     Analyze data    93       **X**        **P                      
                                                           (Center)**               

                     Report analysis 94       **X**        **P                      
                                                           (Center)**               

                     SW Development  102      **X**        **P                      PAL \# 1.2.6.1, "ISD
                     Mgt. Plan                             (Center)**               SMP/PP for Class B &
                                                                                    C Software"

                     SW              103      **P          **P                      PAL \# 3.1, "ISD
                     Configuration            (Center)**   (Center)**               Software
                     Mgt. Plan                                                      Configuration
                                                                                    Management"

                     SW Test Plan    104      **X**        **P                      
                                                           (Center)**               

                     SW Maintenance  105      **P                                   
                     Plan                     (Center)**                            

                     SW Assurance    106      **X**                                 
                     Plan                                                           

  **SW Documen-**    SW Requirements 109      **X**        **P                      
                     Spec.                                 (Center)**               

  **tation**         SW Data         110      **P                                   
                     Dictionary               (Center)**                            

  **Requirements**   SW Design       111      **X**        **P                      
                     Description                           (Center)**               

                     Interface       112      **X**        **P                      
                     Design                                (Center)**               
                     Description                                                    

                     SW Change       113      **X**        **P                      
                     Request/                              (Center)**               
                     Problem                                                        

                     SW Test         114      **X**        **P                      
                     Procedures                            (Center)**               

                     SW Users Manual 115      **X**                                 

                     SW Version      116      **X**        **P                      PAL \# 2.6.1.3, "ISD
                     Description                           (Center)**               Product Release
                                                                                    Letter"

                     SW Metrics      117      **X**        **P                      
                     Report                                (Center)**               

                     SW Test Report  118      **X**        **P                      
                                                           (Center)**               

                     SW Inspection / 119      **P                                   
                     Peer Review              (Center)**                            

  **Compliance**     Compliance      125      **X**        **X**                    This is the
                     Matrix                                                         compliance matrix
                                                                                    for the project.
  ------------------------------------------------------------------------------------------------------