VERSION DESCRIPTION DOCUMENT

The Version Description Document (VDD) describes the contents of the software
being released. For Unique software, it provides the link between the tested and
released version of the software and the specific version in the ISSMP Software
Configuration Management (CM) system. The following provides an overview of
the structure of the VDD.

1.0 SCOPE

Briefly describe the software to which this document applies.

This document describes the software release for the [system name]. It includes all
custom, Government Furnished Software (GFS), and commercial-off-the-shelf
(COTS) software. This software load is used for [indicate if the software load is for
test, training, ground support, and/or flight].

2.0 DOCUMENTS

If an on-orbit update appendix is included in this document include the following

text in section 2.0. Otherwise delete the following text and leave section 2.0 blank.

Appendix [X] identifies changes to any of these document references due to on-
orbit software updates.

2.1 APPLICABLE DOCUMENTS

List all documents that provide requirements for the software.

2.2 REFERENCE DOCUMENTS

List the number, title, revision, and date of all documents referenced in this
document.

2.3 RELATED DOCUMENTS

List by identifying numbers, titles, abbreviations, dates, version numbers, and

release numbers, as applicable, all documents pertinent to the software version
being released but not included in the release (i.e., requirement documents,
design documentation, interface documentation, etc.).

3.0 VERSION DESCRIPTION

3.1 INVENTORY OF SOFTWARE RELEASED

1
 List all components that make up the software version being released. Include
text as needed to document applicable packaging requirements, security and
privacy considerations for these items, instructions and restrictions regarding
duplication and license provisions. The origin or source organization of the
software shall be listed as ISSMP, Principal Investigator (PI) (Specify), COTS
(specify vendor), etc. The part number is the COTS part number or the VDD
number. The serial numbers shall be provided if software is released on physical
media. When software is released via the software configuration management
tool, a read-only tag shall be created and the tag name (i.e., “repository
name/tags/tag name”) provided as the lot number. The meta-checksum is a
checksum generated on all of the files being released as part of a specific
component. A CRC-32 checksum utility and a MD5 checksum utility are
available on the ISSMP CM system. See
https://tdic.jsc.nasa.gov:8443/svn/Check_Sum_Tool/trunk. Use of either is at
project discretion.

TABLE 3.1-1. SOFTWARE RELEASED

Component Origin Version Part Number Serial or Lot Meta
Number Checksum
(optional)

3.2 INVENTORY OF SOFTWARE CONTENTS

This section contains a list of all software components (source and/or

executables) and data files included in the software load being released. For
large releases of custom software the source files may be provided as an
appendix containing the checksum tool report .The origin of the software shall be
listed as ISSMP, PI (Specify), COTS (specify vendor), etc. For COTS
applications, the version of each major program shall be identified. For
example, a VDD for Office 2010 Standard would include the versions for Word,
PowerPoint, Excel, etc. For custom software, the version number used shall be
the version number associated with the tested software in the ISSMP Software
CM system and a checksum for each executable or library file shall be included.
For COTS software being delivered to ISSMP on media other than that provided
by the vendor, a checksum for each file shall be provided. A CRC-32 checksum
utility and a MD5 checksum utility are available on the ISSMP CM system. See
https://tdic.jsc.nasa.gov:8443/svn/Check_Sum_Tool/trunk. Use of either is at
project discretion.

For integrated load VDDs, the checksum is replaced by the component part
number and/or lot number.

If an on-orbit update appendix is included in this document include the following

text in section 3.2. Otherwise delete the following text.

2
 Appendix [X] identifies software version changes due to on-orbit software
updates.

TABLE 3.2-1. SOFTWARE CONTENTS

Component Origin Version Checksum

3.3 CHANGES INSTALLED

This section contains a list of all changes incorporated into the software version
since the previous version. This paragraph does not apply to the initial software
version. Place “None” in the first column of the table below. For subsequent
revisions of the software, place the change request number in the first column and
a summary of the changes in the second column.

If an on-orbit update appendix is included in this document include the following

text in section 3.2. Otherwise delete the following text.

Appendix [X] identifies any changes due to on-orbit software updates.

None.

3.4 ADAPTATION DATA

Identify all post installation configuration data (e.g., configuration files, serial
port configuration, hard drive address letters, changes made for training, etc.)
contained in the software version. Additionally, the operating system version,
operating system setting and any other environmental settings or software
required for execution of the software and not included in the software release
shall be identified.

3.5 INSTALLATION INSTRUCTIONS

Provide or reference the following information, as applicable:

a. Instructions for installing or upgrading the software version

b. Identification of other changes that have to be installed for this version to be
used, including site-unique adaptation data not included in the software
version
c. Security, privacy, or safety precautions relevant to the installation

3
 d. Procedures for determining whether the version has been installed properly

3.6 POSSIBLE PROBLEMS AND KNOWN ERRORS

Identify any possible problems or known errors with the software version at the
time of release, any steps being taken to resolve the problems or errors, and
instructions (either directly or by reference) for recognizing, avoiding,
correcting, or otherwise handling each one.

3.7 CSCI ENVIRONMENT INFORMATION

For each CSCI, identify and list the version for the operating system, compilers,
and any other tools used to develop and test the CSCI. For externally provided
software, this section is not applicable.

4
3.8 UNTESTED REQUIREMENTS

Identify every requirement by number and requirements text that could not be
tested prior to release of the software. For each requirement, provide the test
steps, associated with the software, that are necessary to ensure the requirement
is fully tested during rack integration.

4.0 NOTES

This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall
include a list of any terms and definitions needed to understand this document.
This section shall also contain a description of any characteristics of the software
that were intentionally implemented in the software (as opposed to anomalies
discovered in the software).

A APPENDICES (IF APPLICABLE)

Appendices may be used to provide information published separately for

convenience in document maintenance (e.g., charts, data). As applicable, each
appendix shall be referenced in the main body of the document where the data
would normally have been provided. Appendices may be bound as separate
documents for ease in handling. Appendices shall be lettered alphabetically (A,
B, etc.). If desired, the Human Research Facility On-Orbit Software Change Log
may be included as the last appendix of the document. If it is used, it must be
referenced in Sections 2.1, 3.3, and 3.5. Sample reference text is provided below.

Section 2.1 Documents updated as a result of On-Orbit changes are identified in Appendix
x, HRF On-Orbit Software Change Log.
Section 3.3 Appendix x, HRF On-Orbit Software Change Log contains the list of all
changes made during On-Orbit operations.
Section 3.5 Following installation from the {media source}, the software identified in
Appendix x, HRF On-Orbit Software Change Log, must be installed to achieve
the final On-Orbit configuration.

The change log simplifies tracking of on-orbit changes in the VDD. The table
fields may be customized as needed. The default fields are as follows:

Change Identifies the change request number that authorized the configuration
Authorization change. This field is required.
Incr. Specifies the increment during which the software is targeted for
installation. This field is required

5
R/O Indicates if file must be distributed to all load installations or not.
R - Required – must be installed on all previously distributed loads.
O - Optional – installation on previously distributed loads is not
required. Teams needing to use an optional component must verify
installation of the component on the load prior to use. This field is
required.
Version Description The document number and version of the VDD that contains the change.
Document If this table is being included in the VDD that contains the change, this
column may be omitted.
Platform Identifies the platform where the change will be installed.
Software File Name Identifies the name of the program, configuration file, batch file, data file
and/or script being changed. This field is required.
Uplink File Name Payload MDM filename used for uplink. May be N/A if another uplink
path is used.
Part Number Identifies the part number of the new software component. This field is
required.
Checksum CRC 32 associated with the file being uplinked. This field is required.

6
 APPENDIX X. HUMAN RESEARCH FACILITY ON-ORBIT SOFTWARE CHANGE LOG

Version
Change Old Part New Part Software File Uplink File
Incr.1 R/O2 Description Platform Checksum
Authorization Number3 Number Name Name4
Document
HRF PC
Other: ___________
Change
Description
HRF PC
Other: ___________
Change
Description
HRF PC
Other: ___________
Change
Description
HRF PC
Other: ___________
Change
Description
HRF PC
Other: ___________
Change
Description
HRF PC
Other: ___________
Change
Description

1
Specify the increment during which the software is targeted for installation
2
Indicates whether the file must be distributed to all ground based load installations or not. R - Required – must be installed on all previously distributed loads.
O - Optional – installation on previously distributed loads is not required. Teams needing to use an optional component must verify installation of the component
on the load prior to use.
3
Components created during the integrated load may not have an old part number. In these cases N/A will be used.
4
Payload MDM filename used for uplink. May be N/A if another uplink path is used.