1. Requirements

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.

1.1 Notes

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

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

Retirement should be considered for software that is beyond end-of-life and no longer supported by the software publisher. To retire the software, the following should be specified: (1) the identification of records and software tools to be archived, (2) the location of the archive, and (3) procedures for access.

3. Guidance

The retirement procedures are documented in the Software Maintenance Plan or the Software Development/Management Plan (see Topic 7.18 - Documentation Guidance).  Ensure that the retirement process includes archival and eventual disposal of software assurance records and documents created over the life of the program/project following the requirements of NPR 1441.1, NASA Records Retention Schedules ⁰³⁷.

As stated in NID 7150_113 ⁶⁰³, retirement should be considered for software that is beyond end-of-life and no longer supported by the software publisher. To retire the software, the following should be specified: (1) the identification of records and software tools to be archived, (2) the location of the archive, and (3) procedures for access.

Software recycling is the process of reclaiming software from retired hardware. After NASA acquires the software, it will be regularly evaluated to ensure that it is still necessary and in use. If the software is no longer in use, there are two options. The license can be retired or it can be put into a pool for future re-use.

 When software needs to be retired, the Technical POC, in coordination with the Center CIO or designee, will ensure that several tasks are completed:

(1) Inform the Center CIO or designee about their plans to retire the software,

(2) Stop the software on all running instances (i.e., delete the software from Center IT infrastructure),

(3) Update the Center Inventory to reflect the retired status of the software.

4. Small Projects

No additional guidance is available for small projects.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

1. Confirm that the project has identified the records and software tools for archival.

2. Confirm the project has an archival location and the procedures for archiving and accessing products for software retirement or disposal.

3. Confirm that the project archives all software and records as planned.

7.2 Software Assurance Products

• None at this time.

  
  

  Objective Evidence

  • Software assurance process audit results
  • Evidence of confirmation that all software, software records, and software assurance records, including metrics, have been archived in a planned organizational location.
   Definition of objective evidence

  Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

• None identified at this time.

7.4 Guidance

To confirm that the proper planning has been done for retirement, review the project plan that contains the information on retirement. Most likely that will either be in the project software management/development plan or the software maintenance plan. The information on the records and tools to be archived as well as the planned location for archival files may be in the data management plan. Both the location for the archival files as well as the identification of the files to be archived should be recorded in the project documentation. 

Also, check that the project has documented procedures for archiving and accessing products for software retirement or disposal. The procedures can either be project developed or can be Center level procedures that are referenced and tailored for project use.

As a part of completing the software retirement, verify that all the software, records, and tools identified for archival have been archived unless they are planned for disposal. If tools or software have associated licenses, they need to be transferred or canceled.