07.01. Software Release and Operations Activity Overview

The ultimate goal of software development is to provide a product to the customer. Documentation must accompany that delivery to ensure proper understanding, use, and maintenance of the delivered product.  

Requirements are the basis for building a product that meets the needs of the project. They define the behavior of the system and the constraints under which the problem is to be solved. The implemented product must be verified against the requirements to show that it meets all of the requirements.

However, requirements change over time and the documentation of the requirements is not always up to date. Also, for Agile approaches, not all of the requirements are necessarily documented upfront. It is critical that the Project Manager uses an appropriate method or tool to keep track of the requirements necessary for each delivery of the software and that these are kept up to date with any changes or defect resolutions.

The verification planning, execution, and results should include all requirements for that delivery. A traceability matrix that shows all of the planned and modified requirements for the test procedures/results is critical for showing compliance with this NPR requirement. Also critical are the test reports that show that each requirement verification passed.

Standards and processes are documented in the 5.08 - SDP-SMP - Software Development - Management Plan or in a separate 5.04 - Maint - Software Maintenance Plan.  Each software classification has a defined set of requirements and all software at that classification must meet those requirements for its lifetime or until its classification changes, therefore, the software is maintained according to processes and standards defined for its software classification.

Frequency Of This Activity

Some things that will cause this activity to be performed again include: 

• Changes in requirements
• Changes in architecture or design, including advances in technology 
• Changes in coding, including advances in coding environments or tools
• Changes in testing, including advances in testing environments or tools
• Changes in release or maintenance 

07.01.1 Related SWEs

• SWE-075 - Plan Operations, Maintenance, Retirement - 4.6.2 The project manager shall plan and implement software operations, maintenance, and retirement activities.
• SWE-077 - Deliver Software Products - 4.6.3 The project manager shall complete and deliver the software product to the customer with appropriate records, including as-built records, to support the operations and maintenance phase of the software’s life cycle. 
• SWE-194 - Delivery Requirements Verification - 4.6.4 The project manager shall complete, prior to delivery, verification that all software requirements identified for this delivery have been met or dispositioned, that all approved changes have been implemented, and that all defects designated for resolution prior to delivery have been resolved. 

Reuse SWEs

• SWE-147 - Specify Reusability Requirements - 3.10.1 The project manager shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including the models, simulations, and associated data used as inputs for auto-generation of software, for U.S. Government purposes.
• SWE-148 - Contribute to Agency Software Catalog - 3.10.2 The project manager shall evaluate software for potential reuse by other projects across NASA and contribute reuse candidates to the appropriate NASA internal sharing and reuse software system. However, if the project manager is not a civil servant, then a civil servant will pre-approve all such software contributions; all software contributions should include, at a minimum, the following information:

  a. Software Title.
  b. Software Description.
  c. The Civil Servant Software Technical POC for the software product.
  d. The language or languages used to develop the software.
  e. Any third-party code contained therein, and the record of the requisite license or permission received from the third party permitting the Government’s use and any required markings (e.g., required copyright, author, applicable license notices within the software code, and the source of each third-party software component (e.g., software URL & license URL)), if applicable.
  f. Release notes.

Sharing

• SWE-216 - Internal Software Sharing List - 2.1.5.14 The Center Director, or designee, shall ensure that all software listed on the internal software sharing or reuse catalog(s) conforms to NASA software engineering policy and requirements.
• SWE-217 - List of All Contributors and Disclaimer Notice - 2.1.5.15 The Center Director, or designee, (e.g., the Civil Servant Technical Point of Contact (POC) for the software product) shall perform the following actions:

  a. Keep a list of all contributors to the software product.

  b. Ensure that the software product contains appropriate disclaimer and indemnification provisions (e.g., in a “README” file) stating that the software may be subject to U.S. export control restrictions, and it is provided “as is” without any warranty, express or implied, and that the recipient waives any claims against, and indemnifies and holds harmless, NASA and its contractors and subcontractors.

07.01.2 Related Work Products

• 5.08 - SDP-SMP - Software Development - Management Plan - Minimum recommended content for the Software Development - Management Plan. 
• 5.16 - VDD - Version Description Document - Minimum recommended content for the Version Description Document. 
• 7.08 - Maturity of Life Cycle Products at Milestone Reviews - This chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life cycle products and their maturity level at the various software project life cycle reviews.
• 7.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• A.10 Software Peer Reviews and Inspections - Plans are good candidates for a Peer Review
• 7.19 - Software Risk Management Checklists - tab 7 Software Release Phase checklist, and tab 8 Operations and Maintenance 

07.01.2.1 Related Process Asset Templates

07.01.3 Related Topics

• 8.23 - Software Contents of a Certification of Flight Readiness - Topic discusses the software contents and reviews leading up to a Certification of Flight Readiness (CoFR) for different types of projects.

07.01.4 Related SPAN Links

07.02. Maintenance Activity Overview

Maintenance involves continuing review of the software to determine if further modifications are necessary. These modifications may be necessary to fix defects found in Operations. These modifications will then have to be released and delivered for use. 

07.02.1 Related SWEs

• SWE-075 - Plan Operations, Maintenance, Retirement - 4.6.2 The project manager shall plan and implement software operations, maintenance, and retirement activities.
• SWE-077 - Deliver Software Products - 4.6.3 The project manager shall complete and deliver the software product to the customer with appropriate records, including as-built records, to support the operations and maintenance phase of the software’s life cycle. 
• SWE-194 - Delivery Requirements Verification - 4.6.4 The project manager shall complete, prior to delivery, verification that all software requirements identified for this delivery have been met or dispositioned, that all approved changes have been implemented, and that all defects designated for resolution prior to delivery have been resolved. 
• SWE-195 - Software Maintenance Phase - 4.6.5 The project manager shall maintain the software using standards and processes per the applicable software classification throughout the maintenance phase.

Reuse SWEs

• SWE-147 - Specify Reusability Requirements - 3.10.1 The project manager shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including the models, simulations, and associated data used as inputs for auto-generation of software, for U.S. Government purposes.
• SWE-148 - Contribute to Agency Software Catalog - 3.10.2 The project manager shall evaluate software for potential reuse by other projects across NASA and contribute reuse candidates to the appropriate NASA internal sharing and reuse software system. However, if the project manager is not a civil servant, then a civil servant will pre-approve all such software contributions; all software contributions should include, at a minimum, the following information:

  a. Software Title.
  b. Software Description.
  c. The Civil Servant Software Technical POC for the software product.
  d. The language or languages used to develop the software.
  e. Any third-party code contained therein, and the record of the requisite license or permission received from the third party permitting the Government’s use and any required markings (e.g., required copyright, author, applicable license notices within the software code, and the source of each third-party software component (e.g., software URL & license URL)), if applicable.
  f. Release notes.

Sharing

• SWE-216 - Internal Software Sharing List - 2.1.5.14 The Center Director, or designee, shall ensure that all software listed on the internal software sharing or reuse catalog(s) conforms to NASA software engineering policy and requirements.
• SWE-217 - List of All Contributors and Disclaimer Notice - 2.1.5.15 The Center Director, or designee, (e.g., the Civil Servant Technical Point of Contact (POC) for the software product) shall perform the following actions:

  a. Keep a list of all contributors to the software product.

  b. Ensure that the software product contains appropriate disclaimer and indemnification provisions (e.g., in a “README” file) stating that the software may be subject to U.S. export control restrictions, and it is provided “as is” without any warranty, express or implied, and that the recipient waives any claims against, and indemnifies and holds harmless, NASA and its contractors and subcontractors.

07.02.2 Related Work Products

• 5.04 - Maint - Software Maintenance Plan - Minimum recommended content for the Software Maintenance Plan. 
• 5.16 - VDD - Version Description Document - Minimum recommended content for the Version Description Document. 
• 7.08 - Maturity of Life Cycle Products at Milestone Reviews - This chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life cycle products and their maturity level at the various software project life cycle reviews.
• 7.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• A.10 Software Peer Reviews and Inspections - Plans are good candidates for a Peer Review

07.02.2.1 Related Process Asset Templates

07.02.3 Related Topics

• 8.23 - Software Contents of a Certification of Flight Readiness - Topic discusses the software contents and reviews leading up to a Certification of Flight Readiness (CoFR) for different types of projects.

07.02.4 Related SPAN Links

07.03. Retirement Activity Overview

Retirement should be considered for software that is beyond end-of-life and no longer supported by the software publisher. 

07.03.1 Related SWEs

• SWE-075 - Plan Operations, Maintenance, Retirement - 4.6.2 The project manager shall plan and implement software operations, maintenance, and retirement activities.
• SWE-196 - Software Retirement Archival - 4.6.6 The project manager shall identify the records and software tools to be archived, the location of the archive, and procedures for access to the products for software retirement or disposal.

Reuse SWEs

• SWE-148 - Contribute to Agency Software Catalog - 3.10.2 The project manager shall evaluate software for potential reuse by other projects across NASA and contribute reuse candidates to the appropriate NASA internal sharing and reuse software system. However, if the project manager is not a civil servant, then a civil servant will pre-approve all such software contributions; all software contributions should include, at a minimum, the following information:

  a. Software Title.
  b. Software Description.
  c. The Civil Servant Software Technical POC for the software product.
  d. The language or languages used to develop the software.
  e. Any third-party code contained therein, and the record of the requisite license or permission received from the third party permitting the Government’s use and any required markings (e.g., required copyright, author, applicable license notices within the software code, and the source of each third-party software component (e.g., software URL & license URL)), if applicable.
  f. Release notes.

Sharing

• SWE-216 - Internal Software Sharing List - 2.1.5.14 The Center Director, or designee, shall ensure that all software listed on the internal software sharing or reuse catalog(s) conforms to NASA software engineering policy and requirements.
• SWE-217 - List of All Contributors and Disclaimer Notice - 2.1.5.15 The Center Director, or designee, (e.g., the Civil Servant Technical Point of Contact (POC) for the software product) shall perform the following actions:

  a. Keep a list of all contributors to the software product.

  b. Ensure that the software product contains appropriate disclaimer and indemnification provisions (e.g., in a “README” file) stating that the software may be subject to U.S. export control restrictions, and it is provided “as is” without any warranty, express or implied, and that the recipient waives any claims against, and indemnifies and holds harmless, NASA and its contractors and subcontractors.

07.03.2 Related Work Products

• Archival Documentation 
• 7.19 - Software Risk Management Checklists

07.03.2.1 Related Process Asset Templates

07.03.3 Related Topics

• 8.23 - Software Contents of a Certification of Flight Readiness

07.03.4 Related SPAN Links