SWE-075 - Plan Operations, Maintenance, Retirement

Web Resources

See edit history of this section

Post feedback on this section

Section Labels:

Unknown macro: {page-info}

1. The Requirement
2. Rationale
3. Guidance
4. Small Projects
5. Resources
6. Lessons Learned

1. Requirements

3.5.2 The project shall plan software operations, maintenance, and retirement activities.

1.1 Notes

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

1.2 Applicability Across Classes

Class G 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)

2. Rationale

Per Marshall Space Flight Center's Software Development Process Description Document (EI32-0I-001), "The Software Operation phase spans the time from execution of the software product in the target environment to software retirement. The Software Maintenance phase of the software life cycle begins after successful completion of formal test and delivery of the software product to the customer. This Software Maintenance phase overlaps the Software Operation phase and continues until software retirement or discontinuation of software support." ⁰⁰¹

As with any activity that builds on and relies on previous activities, software operations, maintenance, and retirement requires planning before implementation. The team documents and reviews those plans before they are implemented to allow its members to consider all the tasks, personnel, methods, tools, facilities and related criteria needed to perform those activities.

3. Guidance

The results of planning for operations, maintenance and retirement of software are captured in the Software Maintenance Plan for implementation. In addition to the required contents for the Software Maintenance Plan (SWE-105) and the items listed in this Handbook's guidance for retirement SWE-074, consider the following items for each phase of planning, keeping in mind that operations and maintenance are most often conducted in parallel:

Operations

Software team support of operations, including help desk activities, as applicable.
Documentation required for operations support (e.g., as-built documentation, user's manual, source code, operations notes).
Tools required for operations support (e.g., email systems, servers).
Availability of problem reporting and corrective action (PRACA) system during operations.
Participation in mission debriefs, as appropriate. ⁰⁰¹
Capturing of lessons learned during operations.
Software assurance, including software safety, monitoring activities.
Operational backups (e.g., hot backups for critical systems), including identification and planning of approach.

Maintenance

Modification of software after delivery.
Updates to system and software documentation to align with/reflect these modifications.
Availability and use of a configuration management system for documenting, reviewing, analyzing modifications to code, documentation, and hardware test configurations.
Tools required for maintenance activities (e.g., issue tracking systems, analysis tools, configuration control systems, compilers).
Other resources required to perform maintenance activities such as documentation, development environment, test environment.
Testing of modifications (including pre- and post-delivery).
Delivery and installation of modifications, including generation of associated documentation such as version description documents (VDDs).
Capture of maintenance metrics. ⁰⁰¹
Maintenance transition plan.
Software assurance and software safety activities for updates.

Retirement

Archival of software products, including capture in a configuration management (CM) system. ⁰⁰¹
Retention period for retired software products. ⁰⁰¹
Tools needed to complete retirement activities (e.g., CM system).
Security measures for access to and use of retired software products.
Transition plans for functionality and data if software being retired is being replaced by another software product.

The following personnel roles need to be considered for involvement in the planning of operations, maintenance, and retirement activities:

Software project lead.
Software team.
Project manager.
Software quality engineer (not involved in planning, but in checking on planned activities).
CM officer (role may not exist on all projects).

Planning for maintenance activities, in particular, needs to begin very early in the software development life cycle so that the software is designed for maintainability ²⁷⁶. For NPR 7120.5 projects, this Handbook provides the recommended maturity of the Software Maintenance Plan at major milestone reviews (see 7.08 - Maturity of Life Cycle Products at Milestone Reviews). The lifetime of use for software is not always known, so maintenance becomes easier if the software is designed with maintenance in mind. If there are specific design features that facilitate easier maintenance, those may be candidates for referencing in the Software Maintenance Plan.

Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to planning operations, maintenance, and retirement.

Additionally, guidance related to operations, maintenance, and retirement planning may be found in the following related requirements in this Handbook:

SWE-074	Document Maintenance Plan
SWE-076	Implement Operations, Maintenance, and Retirement Activities
SWE-105	Software Maintenance Plan

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

Click here to view master references table.

(SWEREF-001) Software Development Process Description Document, EI32-OI-001, Revision R, Flight and Ground Software Division, Marshall Space Flight Center (MSFC), 2010. This NASA-specific information and resource is available in Software Processes Across NASA (SPAN), accessible to NASA-users from the SPAN tab in this Handbook.
(SWEREF-037)
NASA Records Management Program Requirements (Updated w/Change 3),
NPR 1441.1E, NASA Office of the Chief Information Officer, Effective Date: January 29, 2015, Expiration Date: January 29, 2024
(SWEREF-157)
CMMI for Development, Version 1.3: Improving processes for developing better products and services,
CMMI Development Team (2010). CMU/SEI-2010-TR-033, Software Engineering Institute.
(SWEREF-197)
Software Processes Across NASA (SPAN)
Software Processes Across NASA (SPAN) web site in NEN SPAN is a compendium of Processes, Procedures, Job Aids, Examples and other recommended best practices.
(SWEREF-209)
IEEE Standard for Software Verification and Validation
IEEE Computer Society, IEEE Std 1012-2012 (Revision of IEEE Std 1012-2004), This link requires an account on the NASA START (AGCY NTSS) system (https://standards.nasa.gov ). Once logged in, users can access Standards Organizations, IEEE and then search to get to authorized copies of IEEE standards.
(SWEREF-215)
IEEE Standard for Software and System Test Documentation,
IEEE Computer Society, IEEE Std 829-2008, 2008. NASA users can access IEEE standards via the NASA Technical Standards System located at https://standards.nasa.gov/. Once logged in, search to get to authorized copies of IEEE standards.
(SWEREF-224)
Systems and software engineering - Software life cycle processes
ISO/IEC 12207, IEEE Std 12207-2008, 2008. IEEE Computer Society, NASA users can access IEEE standards via the NASA Technical Standards System located at https://standards.nasa.gov/. Once logged in, search to get to authorized copies of IEEE standards.
(SWEREF-228)
International Standards Organization (ISO), "Software Engineering - Software Life Cycle Processes - Maintenance,"
ISO/IEC 14764:2006, 2006. NASA users can access IEEE standards via the NASA Technical Standards System located at https://standards.nasa.gov/. Once logged in, search to get to authorized copies of IEEE standards.
(SWEREF-271)
NASA Software Safety Standard,
NASA STD 8719.13 (Rev C ) , Document Date: 2013-05-07
(SWEREF-273)
NASA Systems Engineering Handbook
NASA SP-2016-6105 Rev2,
(SWEREF-276)
NASA Software Safety Guidebook,
NASA-GB-8719.13, NASA, 2004. Access NASA-GB-8719.13 directly: https://swehb.nasa.gov/download/attachments/16450020/nasa-gb-871913.pdf?api=v2
(SWEREF-278)
SOFTWARE ASSURANCE AND SOFTWARE SAFETY STANDARD
NASA-STD-8739.8B , NASA TECHNICAL STANDARD, Approved 2022-09-08 Superseding "NASA-STD-8739.8A,
(SWEREF-525)
Benefits of Implementing Maintainability on NASA Programs
Public Lessons Learned Entry: 835.
(SWEREF-526)
Software Design for Maintainability
Public Lessons Learned Entry: 838.
(SWEREF-540)
Computer Hardware-Software/Software Development Tools/Maintenance
Public Lessons Learned Entry: 1128.
(SWEREF-543)
International Space Station (ISS) Program/Computer Hardware-Software/International Partner Source Code
Public Lessons Learned Entry: 1153.
(SWEREF-550)
ADEOS-II NASA Ground Network (NGN) Development and Early Operations -- Central/Standard Autonomous File Server (CSAFS/SAFS) Lessons Learned
Public Lessons Learned Entry: 1346.

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

6. Lessons Learned

The NASA Lesson Learned database contains the following lessons learned related to maintenance planning:

Benefits of Implementing Maintainability on NASA Programs. Lesson Number 0835: Impact of Non-Practice states: "Maintainability requirements for programs that require ground and/or in-space maintenance and anomaly resolution have to be established early in the program to be cost effective. Lack of management support to properly fund maintainability activities up-front can result in increased program risk. Including maintainability in the design process will greatly reduce the number of operational problems associated with system maintenance, improve the availability of the system, and reduce program costs." ⁵²⁵

Software Design for Maintainability. Lesson Number 0838: Impact of Non-Practice states: "Because of increases in the size and complexity of software products, software maintenance tasks have become increasingly more difficult. Software maintenance should not be a design afterthought; it should be possible for software maintainers to enhance the product without tearing down and rebuilding the majority of code." ⁵²⁶

Content

Space Tools