bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 48 Next »

SWE-085 - Release Management

1. Requirements

4.1.7 The project shall establish and implement procedures for the storage, handling, delivery, release, and maintenance of deliverable software products.

1.1 Notes

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

1.2 Applicability Across Classes

Classes D and Not Safety Critical, E and Not Safety Critical, G, and H are 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

  A_SC 

A_NSC

  B_SC 

B_NSC

  C_SC 

C_NSC

  D_SC 

D_NSC

  E_SC 

E_NSC

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

    P(C)

   

    P(C)

   

    P(C)

    P(C)

Key:    A_SC = Class A Software, Safety Critical | A_NSC = Class A Software, Not Safety Critical | ... | - Applicable | - Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

2. Rationale

It is important to ensure that the delivered software is created from the controlled repository. Configuration management (CM) processes and controls provide the rigor and organization necessary for developers and their customers to have confidence that all changes to the code and documents are included in the released products. It is also important that the released product is stored, maintained, and delivered following a repeatable, controlled process. If a software product is intended to be released outside of a project, to another Center (not within the same project), to a contractor or to an entity outside of NASA, the project must follow release procedures documented in NPR 2210.1, Release of NASA Software, or potentially become liable for violations of the 1958 Space Act. Following NPR 2210.1 helps to identify and protect intellectual property contained in a software release and helps to ensure compliance with federal laws and export requirements (e.g., International Traffic in Arms Regulations (ITAR)).

3. Guidance

NASA-STD-8719.13, NASA Software Safety Standard, 271 states that the "organization responsible for Software Configuration Management shall formally provide and document the release of safety-critical software." 271  As with other CM activities, the CM plan includes the plans and reference the procedures for software release management.

When developing procedures for release management, address all of the following:

  • Preparation of the release package.
  • Creation and delivery of the release package.
  • Storage and maintenance of the release package.

Release management procedures may vary depending of the recipient of the release. Internal releases, such as baselines released for testing, will most likely not require the same set of release activities and considerations as formal releases to external customers. 

Preparation of the Release Package

The STEP (SMA (Safety and Mission Assurance) Technical Excellence Program) Level 2 Software Configuration Management and Data Management course taught by the Westfall Team 343 provides a good list of release planning and scheduling activities.

A checklist of activities to complete may be useful as part of the preparation to create the release package. A list of activities to consider includes:

  • Ensure the proper approvals have been documented and received, including:
    • Software assurance - "Software assurance shall provide objective evidence to the project and NASA SMA of the software's readiness for operational release." 278
    • Certification authority - "There shall be an official certification process established, documented, and conducted prior to the release of any safety-critical software for its intended operational use." 271
    • Release authority – Change Control Board (CCB) or other authorized "owner."
  • Ensure any required acceptance data package has been prepared (see NASA-GB-8719.13, NASA Software Safety Guidebook, 276 for typical content information), including the Version Description Document (VDD) (SWE-116).
  • Ensure all required configuration audits have been completed (SWE-084).
  • Ensure all approved deviations and waivers are documented.
  • Ensure all change requests have been completed and verified.
  • Ensure all documents and training materials are complete, including installation and any special installation needs/support, customization and configuration documents, user and operator guides, and release notes.
  • Ensure all legal issues, such as licensing or export regulations (e.g., ITAR (International Traffic in Arms Regulations)), are addressed, as applicable.
  • Ensure any "ready to ship" reviews are completed.
  • Ensure all applicable portions of NPR 2210.1 373 have been completed, including the development of compliance matrices associated with NPR 7150.2 039, NASA-STD-8739.8, Software Assurance Standard, 278 and NASA-STD-8719.13, NASA Software Safety Standard 276.
  • Ensure all installation sites are prepared to receive and install the release, conducting any pre-installation visits as appropriate.
  • Ensure required support personnel are trained and ready to address issues related to the installed release.

Creation and Delivery of the Release Package

Procedures for creating the release package are used once the preparation steps have been completed and it is time to create the release package. Typically, there is a master copy of the release package and copies are distributed to customers. Depending on Center policy, the master may be created by the CM group and the copies created, packaged, and shipped by another group. Whatever process is used needs to be clearly defined in the release management procedures.

When developing those procedures, consider the following:

  • Identify the scope of the release, including the full set of configuration items (CIs) that are to be included, their versions and revisions.
  • Identify the tools to be used to create the release, including compilers and linkers.
  • Identify the software to be used to create the release, including the operating system, macros, libraries.
  • Identify software and tool options to be used (compiler options, environmental parameters).
  • Identify the procedures for creating the master copy of the release or reference them if captured elsewhere.
  • Identify who generates the master copy of the release package.
  • Document the format, layout, and media for the master.
  • Document the verification process to confirm the master contains the proper CI's.
  • Identify the media to be used for the delivery copies.
  • Document replication procedures to be used to generate copies of the master.
  • Document verification procedures to be used to confirm the copies match the master (keep in mind that compilers can insert dates and times, so byte-by-byte compares need to take this into account).
  • Document any virus checks that need to be run on the copies before delivery to the customer.
  • Document any testing to be performed at the customer site (e.g., regression testing).

When developing procedures for delivery of the created package, consider the following:

  • Document whether the release is a full release, partial release which requires a previous full release to be installed first, or a patch; if all types will be used, procedures for creating and installing each need to be created.
  • Document delivery methods and procedures, including shipping methods, if required.
  • Document security measures to be used when handling and shipping the release.
  • Determine an installation schedule that works with the customer's schedule.
  • Document responsibilities for performing installation and installation testing.
  • Document responsibilities for configuring and/or customizing the installed software.
  • Document plans to revert to an earlier release of the software, as applicable.

Storage and Maintenance of the Release Package

As part of release management, the master needs to be safely and securely stored following documented procedures. When developing procedures for storing and maintaining the release package, consider the following:

  • Document the retention period; e.g., "master copies of code and documentation shall be maintained for the life of the software product" (IEEE SA 1042-1987, IEEE Standard for Software Configuration Management 216)
  • Document how to place the master into the CM system with its unique identifier.
  • Document access restrictions.
  • Document or reference any specific procedures for storing code and documentation for safety or security critical functions.
  • Identify release records, such as the VDD (Version Description Document), to be captured and stored with the release, as applicable.

Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to managing deliverables and releases.

Additional guidance related to CM of deliverable and releases may be found in the following related requirements in this Handbook:

SWE-079

Develop CM Plan

SWE-081

Identify Software Configuration Management Items

SWE-083

Status Accounting

SWE-084

Configuration Audits

SWE-103

Software Configuration Management Plan


4. Small Projects

Projects with limited budgets may choose to follow a common Center or project-level release management procedure rather than have separate procedures for each project. Slight modifications may be required for each project, but the overall master process would not have to be developed or maintained on a per project basis.

5. Resources

5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

Tool nameTypeOwner/SourceLinkDescriptionUser

PTC Integrity

COTS

PTC

http://www.ptc.com/application-lifecycle-management/integrity/lifecycle-manager ...

PTC Integrity is a systems and software lifecycle management (SSLM) and application lifecycle management (ALM) platform used for Process automation and workflow management

IV&V, GSFC

IBM Rational Synergy

COTS

IBM Rational

http://www-01.ibm.com/software/awdtools/synergy ...

"...task-based, integrated configuration management solution for global software development." (NOTE: Briefing states that JSC R2S access for license is required.)

IV&V JSC ?

6. Lessons Learned

There are currently no Lessons Learned identified for this requirement.

  • No labels