bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin


{alias:SWE-063} {tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned} {div3:id=tabs-1} h1. 1. Requirements
Wiki Markup
Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned


Div
idtabs-1

1. Requirements

3.3.5

The

project

shall

provide

a

Software

Version

Description

document

for

each

software

release.

h2. {color:#003366}{*}

1.1

Notes{*}{color} The requirement for the content of a Software Version Description document is defined in Chapter 5. h2. 1.2 Applicability Across Classes Class D and Not Safety Critical is labeled with "P (Center)".  This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.  Class F and Class G are labeled with "X (not OTS)".  This means that this requirement does not apply to off-the-shelf software for these classes. {applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=1|cnsc=1|dsc=1|dnsc=p|esc=1|ensc=0|f=*|g=*|h=0} {div3} {div3:id=tabs-2} h1. 2. Rationale Software systems and work products undergo multiple builds, reviews, and rebuild cycles before reaching a fully operational state.  Even then, modifications, error corrections, expanded requirements sets, and even code reuse on other projects result in newer versions of the coded product.  The configuration control of these versions, many of which may be used simultaneously on different projects, requires detailed descriptions to assure the correct work is being performed on the released version of interest. {div3} {div3:id=tabs-3} h1. 3. Guidance The Software Version Description (SVD) document is the definitive record of all components of a released software work product, whether it is for internal or external release. The SVD defines a set of dependencies among work products that are part of the complete software release. It provides a description of the contents of a specific software work product release, the methods and resources needed to re-create the software work product, known changes, uncorrected problems, as well as differences from the prior software release(s). Use of a template{^}1^ for developing the SVD can ease the initial work load required to develop the baseline SVD. The SVD includes the scheme for the identification and classification of software item records and information items and their versions, how to establish baselines, and version identification and control. The release record identifies, tracks, and controls a configuration item at the time a version (including the baseline version) is released. An SVD document for each release lists the items being delivered, including system and software item versions, traceability to specifications or previous releases, what has been changed, known problems, and workarounds. It may include installation or delivery instructions unique to the version described. Version information may come from the software architecture, the software detailed design, and/or the source code. Problem information may come from inspections, bug tracking or the results of static analysis. If a version control system is used, to be effective, it will include the date, time, and size of each software work product. The resulting information from running a checksum algorithm may be included for additional identification and control of the software work product. NPR 2210.1 "[Release of NASA Software|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=2210&s=1C]" ^2^ provides procedural requirements for developers and organizations to prepare and release software work products external to NASA or between Centers. [Appendix C|http://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_2210_001C_&page_name=AppendixC] of the NPR 2210.1 contains a software release checklist flow chart. A Software Release Request Authorization (SRRA) form may be used in connection with NPR 2210.1 to streamline and condense the workflow required for releasing software. A Software Release Authority is required as a part of the process. Typically, a software usage agreement is required, except when the release of the software occurs between civil servants at the same Center, or within a project. The NPR 2210.1 requires the releasing organization to show compliance with [NASA-Std 8719.13|https://standards.nasa.gov/documents/detail/3314914] ^3^ and [NASA Std-8739.8|https://standards.nasa.gov/documents/detail/3315130] ^4^. The release must also consider federal law provisions in [Section 508|http://www.section508.gov/] of the US Rehabilitation Act. Each software release version must have a version number associated with it. A 'release' consists of all the components and their associated version numbers. ^5^ Versioning keeps the changes straight and allows 'roll back' to previous versions if a bug is found later in the software life cycle (see [SWE-019|SWE-019]). Versioning is part of software configuration management. It involves archiving the source code and keeping previous versions when a new version is entered into the configuration management system. Because an updated {term:SVD} document is released with each version of the software, there may be several SVD documents in circulation if different team members are working on different versions of the software work product. Configuration management and control is necessary for all versions to maintain control and to avoid misinformation. Additional guidance related to the releasing of the SVD may be found in the work products generated by the following related requirements in this handbook: | [SWE-077|SWE-077] | Deliver Software Products | | [SWE-078|SWE-078] | As-built Documentation | | [SWE-103|SWE-103] | Software Configuration Management Plan | | [SWE-105|SWE-105] | Software Maintenance Plan | | [SWE-110|SWE-110] | Software Data Dictionary | | [SWE-115|SWE-115] | Software User Manual | | [SWE-116|SWE-116] | Software Version Description (contents) | {div3} {div3:id=tabs-4} h1. 4. Small Projects There is currently no guidance specific to small projects for this requirement. {div3} {div3:id=tabs-5} h1. 5. Resources # [Software Version Description Template,|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fdocs-nen.nasa.gov%2Fcloudrepo%2FdavXSLT%3Fcfg%3DdavXSLTCfg.FileFolder.xml%26q%3Adb%3D22a784d4-66c3-4299-ad06-4f04adc62f9b%26xsl%3DdavXSLTLib.ViewBasic.xsl%26showHeader%3Dfalse] GRC-SW-TPLT-SVD, 2011 # [Release of NASA Software|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=2210&s=1C], NPR 2210.1C, 2010 # [NASA Software Safety Standard|https://standards.nasa.gov/documents/detail/3314914], NASA STD 8719.13  (Rev B w/ Ch1 of 7/8/2004), 2004 # [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130], NASA STD 8739.8, 2005 # [NASA Software Safety Guidebook,|http://www.hq.nasa.gov/office/codeq/doctree/ngbk871913.htm] NASA-GB-8719.13, 2004 # [NASA Systems Engineering Handbook|http://education.ksc.nasa.gov/esmdspacegrant/Documents/NASA%20SP-2007-6105%20Rev%201%20Final%2031Dec2007.pdf], NASA/SP-2007-6105 Rev1, 2007 # [NASA Systems Engineering Processes and Requirements|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7123&s=1A] with Change 1, NPR 7123.1A, 2009 # [NASA Space Flight Program and Project Management Requirements|http://nodis3.gsfc.nasa.gov/npg_img/N_PR_7120_005D_/NM_7120-81_.pdf], NPR 7120.5D (NM-7120.81), 2009. # [Systems and software engineering \---Content of systems and software lifecycle process information products (Documentation),|http://www.iso.org/iso/catalogue_detail?csnumber=43790] ISO/IEC 15289:2006(E). # [Section 508|http://www.section508.gov/] of the US Rehabilitation Act \\ \\ \\ {refstable}\\ {toolstable} {div3} {div3:id=tabs-6} h2. 6. Lessons Learned A documented lesson from the NASA Lessons Learned database notes the following: *Aquarius Reflector Over-Test Incident - Lesson Number: 2419* \-The Aquarius reflector was damaged by over-testing during a 2007 test in the JPL acoustic test chamber. The root cause was attributed to a procedural deviation, and the proximate cause was identified as a test control system safing feature that did not activate. This may have been affected by the procedural deviation, but more likely resulted from test control software that had not been updated to the current version. The Aquarius Special Review Board issued a set of recommendations that may help to avoid future over-test incidents. ([http://www.nasa.gov/offices/oce/llis/imported_content/lesson_2419.html|http://www.nasa.gov/offices/oce/llis/imported_content/lesson_2419.html]) {div3} {tabclose}

Notes

The requirement for the content of a Software Version Description document is defined in Chapter 5 [of NPR 7150.2, NASA Software Engineering Requirements, Section 5.2.8.]

1.2 Applicability Across Classes

Class D and Not Safety Critical is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement. 

Class F and Class G are labeled with "X (not OTS)." This means that this requirement does not apply to off-the-shelf software for these classes.


applicable
f*
g*
h0
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc1
dnscp
dsc1
ensc0



Div
idtabs-2

2. Rationale

Software systems and work products undergo multiple builds, reviews, and rebuild cycles before reaching a fully operational state. Even then, modifications, error corrections, expanded requirements sets, and even code reuse on other projects result in newer versions of the coded product. The configuration control of these versions, many of which may be used simultaneously on different projects, requires detailed descriptions to assure the correct work is being performed on the released version of interest.


Div
idtabs-3

3. Guidance

The Software Version Description (SVD) document is the definitive record of all components of a released software work product, whether it is for internal or external release. The SVD defines a set of dependencies among work products that are part of the complete software release. It provides a description of the contents of a specific software work product release, the methods and resources needed to re-create the software work product, known changes, uncorrected problems, as well as differences from the prior software release(s). Use of a template

sweref
368
368
for developing the SVD can ease the initial work load required to develop the baseline SVD.

The SVD includes the scheme for the identification and classification of software item records and information items and their versions, how to establish baselines, and version identification and control. The release record identifies, tracks, and controls a configuration item at the time a version (including the baseline version) is released. An SVD document for each release lists the items being delivered, including system and software item versions, traceability to specifications or previous releases, what has been changed, known problems, and workarounds. It may include installation or delivery instructions unique to the version described. Version information may come from the software architecture, the software detailed design, and/or the source code. Problem information may come from inspections, bug tracking or the results of static analysis. If a version control system is used, to be effective, it will include the date, time, and size of each software work product. The resulting information from running a checksum algorithm may be included for additional identification and control of the software work product.

NPR 2210.1C, Release of NASA Software,

sweref
373
373
provides procedural requirements for developers and organizations to prepare and release software work products external to NASA or between Centers. Appendix C of the NPR 2210.1 contains a software release checklist flow chart. A Software Release Request Authorization (SRRA) form may be used in connection with NPR 2210.1 to streamline and condense the workflow required for releasing software. A Software Release Authority is required as a part of the process. Typically, a software usage agreement is required, except when the release of the software occurs between civil servants at the same Center, or within a project. The NPR 2210.1 requires the releasing organization to show compliance with NASA-STD-8719.13, NASA Software Safety Standard,
sweref
271
271
and NASA-STD-8739.8, Software Assurance Standard
sweref
278
278
. The release must also consider federal law provisions in Section 508
sweref
404
404
of the US Rehabilitation Act.

Each software release version must have a version number associated with it. A "release" consists of all the components and their associated version numbers.

sweref
276
276
Versioning keeps the changes straight and allows "roll back" to previous versions, if a bug is found later in the software life cycle (see SWE-019). Versioning is part of software configuration management. It involves archiving the source code and keeping previous versions when a new version is entered into the configuration management system. Because an updated SVD (Software Version Description) document is released with each version of the software, there may be several SVD documents in circulation if different team members are working on different versions of the software work product. Configuration management and control is necessary for all versions to maintain control and to avoid misinformation.

Additional guidance related to the releasing of the SVD may be found in the work products generated by the following related requirements in this Handbook:


SWE-077

Deliver Software Products

SWE-078

As-built Documentation

SWE-103

Software Configuration Management Plan

SWE-105

Software Maintenance Plan

SWE-110

Software Data Dictionary

SWE-115

Software User Manual

SWE-116

Software Version Description (contents)



Div
idtabs-4

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.


Div
idtabs-5

5. Resources


refstable

toolstable


Div
idtabs-6

6. Lessons Learned

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

Aquarius Reflector Over-Test Incident. Lesson Number 2419.  "The Aquarius reflector was damaged by over-testing during a 2007 test in the JPL acoustic test chamber. The root cause was attributed to a procedural deviation, and the proximate cause was identified as a test control system safing feature that did not activate. This may have been affected by the procedural deviation, but more likely resulted from test control software that had not been updated to the current version. The Aquarius Special Review Board issued a set of recommendations that may help to avoid future over-test incidents

sweref
573
573
."