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.
According to ISO/IEC/IEEE 24765:2010 Systems and software engineering--Vocabulary, a version description document is “a document that accompanies and identifies a given version of a system or component ... Typical contents include an inventory of system or component parts, identification of changes incorporated into this version, and installation and operating information unique to the version described.”
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 for developing the SVD can ease the initial work load required to develop the baseline SVD. The recommendation for the content of a Software Version Description document is defined in the SVD section of topic 7.18 - Documentation Guidance in this Handbook.
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.
Each software release version must have a version number associated with it. A "release" consists of all the components and their associated version numbers. 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 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.
NASA-specific planning information and resources for development of the software version description document are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.
Additional guidance related to the releasing of the SVD may be found in the work products generated by the following related requirement in this Handbook: