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-116} {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

5.2.8.1

The

Software

Version

Description

shall

identify

and

provide:

\[

(SWE-116

\]

)

a.

Full

identification

of

the

system

and

software

(e.g.,

numbers,

titles,

abbreviations,

version

numbers,

and

release

numbers).


b.

Executable

software

(e.g.,

batch

files,

command

files,

data

files,

or

other

software

needed

to

install

the

software

on

its

target

computer).


c.

Software

life-cycle

data

that

defines

the

software

product.


d.

Archive

and

release

data.


e.

Instructions

for

building

the

executable

software,

including,

for

example,

the

instructions

and

data

for

compiling

and

linking

and

the

procedures

used

for

software

recovery,

software

regeneration,

testing,

or

modification.


f.

Data

integrity

checks

for

the

executable

object

code

and

source

code.


g.

Software

product

files

(any

files

needed

to

install,

build,

operate,

and

maintain

the

software).


h.

Open

change

requests

and

or

problem

reports,

including

any

workarounds.


i.

Change

requests

and/or

problem

reports

implemented

in

the

current

software

version

since

the

last

Software

Version

Description

was

published.

h2. {color:#003366}{*}

1.1

Notes{*}{color} NPR

Notes

NPR 7150.2

does not include any notes for this requirement. h2.

, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2

Applicability

Across

Classes

Classes

C

through

E

,

and

Safety

Critical

are

labeled

with

"P

(Center)"

and

"SO."

. 

"P

(Center)"

means

that

an

approved

Center-defined

process

which

that meets

a

non-empty

subset

of

the

full

requirement

can

be

used

to

achieve

this

requirement.

 

  "SO"

means

that

the

requirement

applies

only

for

safety

-critical

portions

of

the

software.

Classes

C

and

D

and

Not

Safety

Critical

are

labeled

with

"P

(Center)."

.  

This

means

that

an

approved

Center-defined

process

which

that 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

 

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=*|cnsc=p|dsc=*|dnsc=p|esc=*|ensc=0|f=1|g=1|h=0} {div3} {div3:id=tabs-2} h1. 2. Rationale Per chapter 5 of NPR 7150.2, "The Software Version Description (SVD) identifies and describes a software version consisting of one or more CSCIs (including any open source software).  The description is used to release, track, and control a software version." In the event that a project needs to analyze an event that happened in the past, an SVD is a concise record of the software that was running at that time. The precision and completeness of the data entries called for in the required content assure that the correct software is made available and used in its intended application, whether it is being released to other software team members, testing, integration, or to production. The SVD facilitates product implementation, testing, operations, and maintenance. {div3} {div3:id=tabs-3} h1. 3. Guidance The Software Version Description (SVD) 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). Version information may come from the source code. Problem information may come from bug tracking or the results of static analysis. If a version control system is used, it typically includes the date, time, and size of each software work product. The SVD includes a 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. A SVD may consist of one or more types of software items. It lists 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. Because an 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. See the lessons learned for an example when configurations were not properly managed. Below are descriptions of the required content for the SVD for class A and class B software along with examples and guidance for each.  Section 1.2 above presents the approaches to consider for the remaining classes of software. * Full identification of the system and software ** Include identification numbers, titles, abbreviations, version number(s), release number(s) ** Identify intended recipients(source code might not be released to all participants) * Executable software ** Include identification numbers, titles, abbreviations, version number(s), release number(s) ** Identify target computer, files, source code ** Identify any needed executable software necessary to install the software work product release ** Include version descriptions for systems, CSCIs, etc., to the lowest configuration management unit ** List any security and/or privacy considerations * Software life cycle data that defines the software product. ** Requirements: what is satisfied by the release of the software? ** Design: design documents that are fulfilled by the release of the software? ** Test:  test documents used during the software verification ** Configuration: maintenance and reproduction documents ** User: manuals for installing and using the released software ** Management: governing development plans for the software ** Quality: plans and procedures used to assure the quality of the software * Archive and release data. ** Include identification numbers, titles, abbreviations, version number(s), release number(s) in documents describing the software and the associated life cycle data ** Version control system and archival location information * Instructions for building the executable software ** Minimum system requirements and needed user environment ** Installation instructions applicable to the version release ** Identification of other changes still required to make the code useable ** Security, privacy, and safety precautions, if any ** Installation verification procedures ** Details needed to build the executable software *** Instructions and data for compiling and linking *** Procedures for software recovery, software regeneration, testing, or modification * Data integrity checks for the executable object code and source code. ** Applicable security and privacy considerations ** Handling procedures and safeguards * Software product files ** Files needed to install, build, operate, and maintain the software work product * Open change requests and or problem reports, including any workarounds. ** Identify known errors or updates not yet installed for the current release ** Instructions or work-arounds for handling these software work product deficiencies ** Document change request listings ** List known waivers that were approved ** Summarized effects of these waivers on the release versions operation and performance * Change requests and/or problem reports ** Describes the completed changes and their impact on performance and operation ** Identify known unsupported requirements for the current release version ** Describe interfaces to other software that are impacted by this version ** Identify changes affecting only the current version Additional guidance related to the content for the SVD may be found in the work products generated by the following related requirements in this handbook: | *[SWE-063|SWE-063]* | Release Version Description | | *[SWE-103|SWE-103]* | Software Configuration Management Plan | | *[SWE-104|SWE-104]* | Software Test Plan | | *[SWE-105|SWE-105]* | Software Maintenance Plan | | *[SWE-110|SWE-110]* | Software Data Dictionary | | *[SWE-111|SWE-111]* | Software Design Description | | *[SWE-112|SWE-112]* | Interface Design Description | | *[SWE-115|SWE-115]* | Software User Manual | \\ {div3} {div3:id=tabs-4} h1. 4. Small Projects This requirement applies equally to all projects.  The project's software configuration management system can assist the developer in identifying software products and documentation that belong to a particular release. {div3} {div3:id=tabs-5} h1. 5. Resources # [Software Version Description Template,|http://software.grc.nasa.gov/templates.html] GRC-SW-TPLT-SVD, 2011 # [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 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 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 life cycle process information products (Documentation),|http://specs4.ihserc.com/DocViewFrame.aspx?sess=840961521&prod=SPECS4&docid=QGHBJBAAAAAAAAAA] ISO/IEC 15289:2006(E) \\ {refstable} {toolstable} {div3} {div3:id=tabs-6} h2. 6. Lessons Learned A documented lesson from the NASA Lessons Learned database notes the following: *Take CM Measures to Control the Renaming and Reuse of Old Command Files; Lesson Number \-1481* The Mars Odyssey mission ran into a version control issue when they discovered an improperly named file call script. It was determined that the team had taken an old Mars Global surveyor file to reuse.  The file was renamed but its code creation time that was captured in the header was not changed. This caused the system to label the file as an old file. As a result the operations team had to manually specify the correct file to use, until subsequent code fixes were implemented.  ([http://www.nasa.gov/offices/oce/llis/1481.html|http://www.nasa.gov/offices/oce/llis/1481.html]) {div3} {tabclose}


applicable
f1
g1
h0
ansc1
asc1
bnsc1
csc*
bsc1
esc*
cnscp
dnscp
dsc*
ensc0



Div
idtabs-2

2. Rationale

In accordance with section 5.2.8 of NPR 7150.2, "The Software Version Description identifies and describes a software version consisting of one or more CSCI (Computer Software Configuration Item) s (including any open source software). The software version description (SVD) document is used to release, track, and control a software version." In the event that a project needs to analyze an event that happened in the past, an SVD is a concise record of the software that was delivered and executed.

The precision and completeness of the data entries called for in the required content assure that the correct software is made available and used in its intended application, whether it is being released to other software team members, testing, integration, or production. The SVD facilitates product implementation, testing, operations, and maintenance.


Div
idtabs-3

3. Guidance

The SVD 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 recreate the software work product, known changes, uncorrected problems, as well as differences from the prior software release(s).

Version information may come from the source code. Problem information may come from bug tracking or the results of static analysis. If a version control system is used, it typically includes the date, time, and size of each software work product.

The SVD includes a 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 may consist of one or more types of software items. It lists 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. Because an 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 are necessary for all versions to maintain control and to avoid misinformation. See the lessons learned for an example of when configurations were not properly managed.

Below are descriptions of the required content for the SVD for class A and class B software, along with examples and guidance for each. Section 1.2 above presents the approaches to consider for the remaining classes of software.

  • Full identification of the system and software.
    • Include identification numbers, titles, abbreviations, version number(s), release number(s).
    • Identify intended recipients (source code might not be released to all participants).
  • Executable software.
    • Include identification numbers, titles, abbreviations, version number(s), release number(s).
    • Identify target computer, files, source code.
    • Identify any needed executable software necessary to install the software work product release.
    • Include version descriptions for systems, CSCIs, etc., to the lowest configuration management unit.
    • List any security and/or privacy considerations.
  • Software life-cycle data that defines the software product.
    • Requirements: what is satisfied by the release of the software?
    • Design: what design documents are fulfilled by the release of the software?
    • Test:  test documents used during the software verification.
    • Configuration: maintenance and reproduction documents.
    • User: manuals for installing and using the released software.
    • Management: governing development plans for the software.
    • Quality: plans and procedures used to assure the quality of the software.
  • Archive and release data.
    • Include identification numbers, titles, abbreviations, version number(s), release number(s) in documents describing the software and the associated life-cycle data.
    • Version control system and archival location information.
  • Instructions for building the executable software.
    • Minimum system requirements and needed user environment.
    • Installation instructions applicable to the version release.
    • Identification of other changes still required to make the code usable.
    • Security, privacy, and safety precautions, if any.
    • Installation verification procedures.
    • Details needed to build the executable software.
      • Instructions and data for compiling and linking.
      • Procedures for software recovery, software regeneration, testing, or modification.
  • Data integrity checks for the executable object code and source code.
    • Applicable security and privacy considerations.
    • Handling procedures and safeguards.
  • Software product files.
    • Files needed to install, build, operate, and maintain the software work product.
  • Open change requests and/or problem reports, including any workarounds.
    • Identify known errors or updates not yet installed for the current release.
    • Identify instructions or workarounds for handling these software work product deficiencies.
    • Document change request listings.
    • List known waivers that were approved.
    • List summarized effects of these waivers on the release version's operation and performance.
  • Change requests and/or problem reports.
    • Describe the completed changes and their impact on performance and operation.
    • Identify known unsupported requirements for the current release version.
    • Describe interfaces to other software impacted by this version.
    • Identify changes affecting only the current version.

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


SWE-063

Release Version Description

SWE-103

Software Configuration Management Plan

SWE-104

Software Test Plan

SWE-105

Software Maintenance Plan

SWE-110

Software Data Dictionary

SWE-111

Software Design Description

SWE-112

Interface Design Description

SWE-115

Software User Manual




Div
idtabs-4

4. Small Projects

This requirement applies equally to all projects, regardless of size. The project's software configuration management system can assist the developer in identifying software products and documentation that belong to a particular release.


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:

Take Configuration Management (CM) Measures to Control the Renaming and Reuse of Old Command Files. Lesson Number 1481: The Mars Odyssey mission ran into a version control issue when they discovered an improperly named file call script. It was determined that the team had taken an old Mars Global surveyor file to reuse. The file was renamed, but its code creation time captured in the header was not changed. This caused the system to label the file as an old file. As a result, the operations team had to manually specify the correct file to use, until subsequent code fixes were implemented.

sweref
556
556