bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Old Version 2

changes.mady.by.user [DISABLED] Dallas, Lisa (GSFC-5830)

Saved on

compared with

New Version 55

changes.mady.by.user Haigh, Fred Douglas. (HQ-KA000)[PEROT]

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
Wiki Markup
{alias:SWE-077} {tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned} {div3:id=tabs-1} h1. 1. Requirements
Div
idtabs-1

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.

h2. {color:#003366}{*}

1.1

Notes{*}{color} Delivery

Notes

Delivery includes,

as

applicable,

Software

User's

Manual

(as

defined

in

Chapter 5), 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. h2. 1.2 Applicability Across Classes {applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=1|cnsc=1|dsc=1|dnsc=1|esc=1|ensc=p|f=1|g=p|h=0} {div3} {div3:id=tabs-2} h1. 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. {div3} {div3:id=tabs-3} h1. 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^1^ * Software safety plan^2^ * Hazard analyses^2^ * Safety-critical software development audit reports^2^ * Safety-related verification reports^2^ * Installation instructions, including description of hardware environment^3^ * Operational constraints, including environmental limitations^3^ * Configuration files^3^ * Project documentation (e.g., software development/management plan (SDP/SMP), assurance plan, software requirements document (SRS), design documents, configuration management plan (CMP), test plan)^3^ * Testing performed and the results of those tests^3^ * Training manuals4, training agreement^5^ * Maintenance/service/support agreement, processes, procedures^5^ 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."^1^ Delivery package contents from a contracted software provider needs 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, security6 and method for all deliverables * Acceptance criteria ([SWE-034]) See the Acquisition Guidance topic in this handbook for additional guidance regarding delivery for contracted software development. {note}Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to delivery of software products. {note} Additionally, guidance related to delivery of software products may be found in the following requirements in this handbook: |[SWE-034]|Acceptance Criteria| |[SWE-038]|Acquisition Planning| |[SWE-078]|As-built Documentation| |[SWE-116]|Software Version Description| {div3} {div3:id=tabs-4} h1. 4. Small Projects No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph. {div3} {div3:id=tabs-5} h1. 5. Resources # NASA Technical Standard, [NASA Software Assurance Standard|https://standards.nasa.gov/documents/detail/3315130], NASA-STD-8739.8, 2004. # NASA Technical Standard, ["NASA Software Safety Standard"|https://standards.nasa.gov/documents/detail/3314914], NASA-STD-8719.13B, 2004. # NASA Technical Standard, ["NASA Software Safety Guidebook"|https://standards.nasa.gov/documents/detail/3315126], NASA-GB-8719.13, 2004. # NASA Procedural Requirement, ["NASA Systems Engineering Processes and Requirements w/ Change 1"|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7123&s=1A], NPR 7123.1A, 2009. # ["Systems and software engineering - Software life cycle processes"|http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4475826&tag=1], ISO/IEC 12207, IEEE Std 12207-2008, 2008. This link requires an account on the NASA START (AGCY NTSS) system [(http://standards.nasa.gov)|http://standards.nasa.gov/]. Once logged in, users can access Standards Organizations, IEEE and then search to get to authorized copies of IEEE standards. # NASA Scientific and Technical Information (STI), NASA Center for AeroSpace Information, ["NASA Systems Engineering Handbook"|http://www.ap233.org/ap233-public-information/reference/20080008301_2008008500.pdf], NASA/SP-2007-6105, Rev1, 2007. # Software Engineering Institute, ["CMMI for Development, Version 1.3"|http://www.sei.cmu.edu/reports/10tr033.pdf], CMU/SEI-2010-TR-033, 2010 (particularly the Product Integration (PI) section). # Flight and Ground Software Division, MSFC, ["Software Development Process Description Document"|https://nen.nasa.gov/web/software/nasa-software-process-asset-library-pal?p_p_id=webconnector_WAR_webconnector_INSTANCE_PA7b&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_count=1&_webconnector_WAR_webconnector_INSTANCE_PA7b_edu.wisc.my.webproxy.URL=https%3A%2F%2Fnx.arc.nasa.gov%2Fnx%2Fdsweb%2FGet%2FDocument-499471%2FSDPDD_Rev%2BQ_080207.pdf], EI32-OI-001, Revision R, 2010 . {toolstable} {div3} {div3:id=tabs-6} h2. 6. Lessons Learned The NASA Lesson Learned database contains the following lessons learned related to delivery of software products: * *Provide Detailed WBS for Flight Software in the RFP, Lesson Number: 0911* "This organizational segregation of flight software from the spacecraft subsystems leads to a "lack of ownership" of the subsystem flight software by the Subsystem Manager. Typically, the Subsystem Manager is only concerned that he finalize his requirements and design prior to Spacecraft CDR. This in turn leads to late delivery of flight software ICDs, requirements, design algorithms, data constants, and test cases from the subsystem to the Flight Software Manager." ([http://www.nasa.gov/offices/oce/llis/0911.html]) * *Firmware Documentation*: "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." ([http://www.nasa.gov/offices/oce/llis/1024.html]) {div3} {tabclose}

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.


applicable
f1
g1
h0
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc1
dnsc1
dsc1
enscp
 Div
idtabs-2
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.
 Div
idtabs-3
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.
    sweref
    278
    278
  • Software safety plan.
    sweref
    271
    271
  • Hazard analyses.
    sweref
    271
    271
  • Safety-critical software development audit reports.
    sweref
    271
    271
  • Safety-related verification reports.
    sweref
    271
    271
  • Installation instructions, including description of hardware environment.
    sweref
    276
    276
  • Operational constraints, including environmental limitations.
    sweref
    276
    276
  • Configuration files.
    sweref
    276
    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).
    sweref
    276
    276
  • Testing performed and the results of those tests.
    sweref
    276
    276
  • Training manuals
    sweref
    041
    041
    , training agreement.
    sweref
    224
    224
  • Maintenance/service/support agreement, processes, procedures.
    sweref
    224
    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."
sweref
278
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.
    sweref
    273
    273
     and method for all deliverables.
  • Acceptance criteria (SWE-034).
See Topic 7.03 - Acquisition Guidance in this Handbook for additional guidance regarding delivery for contracted software development.

 Note
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
 Div
idtabs-4
4. Small Projects
No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.
 Div
idtabs-5
5. Resources

refstable


toolstable
 Div
idtabs-6
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." 
    sweref
    534
    534



    
    






    
	

    
    
    



    




    
    

    
    
    






        



        

    

    



										
								
		        

		    



		
						
 











Page Editor: Tim Crumbley 

NASA Official: Tim Crumbley






NASA Software Engineering Handbook - A service of the NASA Office of the Chief Engineer

 NASA Privacy Statement

______________________________________________________________________________