2. Rationale

Software operations, maintenance, and retirement activities are planned in order to provide a written or electronic file on how to operate the software, modify and retest the software and provide information on where to archive the software products, the software development environment, and software test environment products and tools.

3. Guidance

Operations, maintenance, and retirement activities are typically planned concurrently. The results of planning these activities for software may be captured as part of an implementation plan or may be part of another project document such as the Software Management Plan (SMP) or Software Maintenance Plan. For existing processes that may be used during operations, maintenance, and retirement, it is acceptable to simply reference existing project documents that describe those processes.

A software maintenance plan can be a combined document that is used during the software operation period.  The software maintenance plan document can combine and replace the software development plan, software configuration plan and software test plan(s).  The software user’s manual addresses how to operate the software.  The software retirement plans can be contained in the software maintenance plan or other document.

"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." ⁰⁰¹

The planning for these life-cycle phases is usually minimal at the beginning of a project and becomes more complete and mature as the software life cycle proceeds.  The maturation of the planning is reflected in the documentation. This Handbook provides the recommended maturity of life cycle plans, including the Software Maintenance Plan, at major milestone reviews (see topic 7.08 - Maturity of Life-Cycle Products at Milestone Reviews).

The project team baselines the plan(s) for operations, maintenance, and retirement before carrying out those life-cycle phases.  Baselining the plan(s) ensures that the team carrying out the operations, maintenance, and retirement activities executes only approved plan(s). Software Assurance personnel are responsible for assuring that these activities are carried out per the baselined plan(s).

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.

There are fewer reasons for the operations, maintenance, and retirement plan(s) to require revision than plans used for the earlier life-cycle phases, but keep the following in mind as a non-exhaustive list of events that could cause the plan(s) to require updating:

• Changes in resource levels, availability (e.g., tools, facilities, personnel).
• In response to new or revised risks.
• Budget changes.
• Changes in stakeholders/stakeholder needs.
• Changes in processes used for operations, maintenance, retirement (e.g., reporting processes, review processes, record keeping processes).

As with other project documents, updates to the plan(s) for operations, maintenance, and retirement are reviewed and approved before being implemented.

In addition to the recommended contents for the Software Maintenance Plan (see Maint) 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.
• 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.
• Mission support procedures for troubleshooting software problems. ⁰⁰¹
• Test of ground displays and software during mission sequence tests or other end-to-end tests. ⁰⁰¹
• Performance assessments, as applicable. ²⁷³
• Training for replacement operators and maintainers. ²⁷³

Maintenance

• Plans for maintaining a piece of software, especially in the case that an organization assumes responsibility for maintaining a piece of software developed by another organization.
• 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, and 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.
• Corrective maintenance for software defects. ⁰⁰¹
• Adaptive maintenance for "software changes necessitated by other changes, usually to the hardware." ⁰⁰¹
• Changing requirements maintenance. ⁰⁰¹
• Operational data maintenance to support system configuration changes needed to use the software. ⁰⁰¹
• Maintenance after new revisions of the software are released.
• User notification of 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.
• Archival of project metrics data. ⁰⁰¹
• Software safety (if not addressed in the software safety plan). ²⁷¹
• User notification of retirement. ²⁰⁹
• Decommissioning and disposal. ²⁷³
• Capture of Lessons Learned. ²⁷³

Other

• Disposition of commercial off-the-shelf (COTS) components (source code, licenses, etc.).
• Support, if required from a contracted developer (established via contract or other agreement).
• Support tools required for operations, maintenance, retirement activities, including how to address obsolescence of any such tools over the operational life of the project.
• Allocation of responsibilities for operations support, maintenance, retirement activities. ²⁷³

The following personnel roles should 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 topic 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.

Additionally, guidance related to operations, maintenance, and retirement planning may be found in topic 7.18 - Documentation Guidance in this Handbook.

4. Small Projects

To facilitate planning activities for projects with limited staff or budgets, consider adapting a maintenance plan from a similar project making sure to update the plan to reflect the current project's operations, maintenance, and retirement plans. The contents of a maintenance plan can also be addressed as sections in another project document and is not required to be in a separate document.

5. Resources

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." ⁵²⁶
• Computer Hardware-Software/Software Development Tools/Maintenance. Lesson Number 1128: "NASA concurs with the finding that no program-wide plan exists addressing the maintenance of Commercial Off the Shelf (COTS) software development tools. A programmatic action has been assigned to develop the usage requirements for COTS/modified off-the-shelf software including the associated development tools. These guidelines will document maintenance and selection guidelines to be used by all of the applicable program elements." ⁵⁴⁰
• International Space Station (ISS) Program/Computer Hardware-Software/International Partner Source Code (Maintenance Agreements.) Lesson Number 1153:  The Recommendation states to "Solidify long-term source code maintenance and incident investigation agreements for all software being developed by the International Partners as quickly as possible, and develop contingency plans for all operations that cannot be adequately placed under NASA's control." ⁵⁴³
• ADEOS-II NASA Ground Network (NGN) Development and Early Operations – Central/Standard Autonomous File Server (CSAFS/SAFS) Lessons Learned (Tools for Maintenance.) Lesson Number 1346:Lesson Learned No. 3 states: "Install, operate and maintain the COTS [Commercial Off-the-Shelf] field and lab components. The following lessons were learned in the installation and operation phase of the SAFS/CSAFS [Standard/Central Standards Autonomous File Server] development.
  
  • "Personally perform on-site installations whenever possible.
  • "Have support/maintenance contracts for hardware and software through development, deployment, and first year of operation.
  • "Create visual representations of system interactions where possible.
  • "Obtain feedback from end users.
  • "Maintain the prototype system after deployment.
  • "Select COTS products with the ability to do internal logging."  ⁵⁵⁰