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 37 Next »

Error rendering macro 'alias'

null

SWE-077 - Deliver Software Products

1. Requirements

3.5.4 The project shall complete and deliver the software product to the customer with appropriate documentation to support the operations and maintenance phase of the software's life cycle.

1.1 Notes

Delivery includes, as applicable, Software User's Manual (as defined in Chapter 5 [of NPR 7150.2, NASA Software Engineering Requirements, Section 5.2.7]), source files, executable software, procedures for creating executable software, procedures for modifying the software, and a Software Version Description. Open source software licenses are reviewed by the Center's Chief of Patent/Intellectual Property Counsel before being accepted into software development projects. Other documentation considered for delivery includes:

          a. Summary and status of all accepted Change Requests to the baselined Software Requirements Specifications.
          b. Summary and status of all major software capability changes since baselining of the Software Design Documents.
          c. Summary and status of all major software tests (including development, verification, and performance testing).
          d. Summary and status of all Problem Reports written against the software.
          e. Summary and status of all software requirements deviations and waivers.
          f. Summary and status of all software user notes.
          g. Summary and status of all quality measures historically and for this software.
          h. Definition of open work, if any.
          i. Software configuration records defining the verified and validated software, including requirements verification data (e.g., requirements verification matrix).
          j. Final version of the software documentation, including the final Software Version Description document(s).
          k. Summary and status of any open software-related risks.

1.2 Applicability Across Classes

Class E Not Safety Critical is labeled as "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)

   

   

   

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

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

3. Guidance

Typical contents of a software delivery package for a completed software project include executables (the product), a user's manual, and a version description document that describes the delivered product. Other items listed in the note for this NPR 7150.2 requirement may also be part of the delivery package as appropriate for the project and its software classification (SWE-020). It is important, however, to keep in mind that the note which accompanies the requirement is only additional information and is not part of the requirement.

In addition to the items listed in this requirement, consider the following items for the software delivery package:

  • Certifications. 278
  • Software safety plan. 271
  • Hazard analyses. 271
  • Safety-critical software development audit reports. 271
  • Safety-related verification reports. 271
  • Installation instructions, including description of hardware environment. 276
  • Operational constraints, including environmental limitations. 276
  • Configuration files. 276
  • Project documentation (e.g., software development/management plan (SDP/SMP), assurance plan, software requirements specification (SRS), design documents, configuration management plan (CMP), test plan). 276
  • Testing performed and the results of those tests. 276
  • Training manuals 041, training agreement. 224
  • Maintenance/service/support agreement, processes, procedures. 224
  • Development environment (any specialized hardware and software needed to build the executable software during the maintenance phase).
  • Hardware needed to test the software, if specialized hardware is needed (for maintenance).

Both the delivered software and the delivered documentation are generated/pulled from the project's configuration management system (SWE-085) as a baseline to ensure the latest versions are delivered to the customer.

It is important to perform an audit prior to delivery to ensure that "all delivered products are complete, contain the proper versions, and that all discrepancies, open work, and deviations and waivers are properly documented and approved." 278

Delivery package contents from a contracted software provider need to be fully described in the contract to ensure the acquirer receives all critical information required to operate and maintain the software. Other contract considerations related to delivery include:

  • Ownership and delivery of source code.
  • Usage considerations for off-the-shelf (OTS) software.
  • Delivery format, security. 273 and method for all deliverables.
  • Acceptance criteria (SWE-034).

See Topic 7.3 - Acquisition Guidance in this Handbook for additional guidance regarding delivery for contracted software development.

Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to delivery of software products.

Additionally, guidance related to delivery of software products may be found in the following related requirements in this Handbook:

SWE-034

Acceptance Criteria

SWE-038

Acquisition Planning

SWE-078

As-built Documentation

SWE-116

Software Version Description

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.

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.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.

6. Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following:

  • International Space Station (ISS) Program/Command and Data Handling/Firmware Documentation (Firmware Documentation.) Lesson Number 1024: "NASA should ensure that all firmware code...is properly documented and archived for future reference. Further, NASA should ensure that it retains the rights to such software.... Direction to deliver copies of the documentation (requirement, design, test, etc.) of the firmware controller software prepared as part of their software development process is being given to each vendor." 534
  • No labels