1. Requirements

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

2. Rationale

Software operations, maintenance, and retirement activities are planned 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 maybe 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 documents.

"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 the successful completion of the 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 execute only the 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 5.04 - Maint - Software Maintenance Plan) 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.

  Swerefn
  refnum 001

• Test of ground displays and software during mission sequence tests or other end-to-end tests.

  Swerefn
  refnum 001

• Performance assessments, as applicable.

  Swerefn
  refnum 273

• Training for replacement operators and maintainers.

  Swerefn
  refnum 273

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 are 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).
• The capture of maintenance metrics.

  Swerefn
  refnum 001

• Maintenance transition plan.
• Software assurance and software safety activities for updates.
• Corrective maintenance for software defects.

  Swerefn
  refnum 001

• Adaptive maintenance for "software changes necessitated by other changes, usually to the hardware."

  Swerefn
  refnum 001

• Changing requirements maintenance.

  Swerefn
  refnum 001

• Operational data maintenance to support system configuration changes needed to use the software.

  Swerefn
  refnum 001

• Maintenance after new revisions of the software is released.
• User notification of updates.

  Swerefn
  refnum 209

Retirement

• Archival of software products, including capture in configuration management (CM) system.

  Swerefn
  refnum 001

• The 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 the software being retired is being replaced by another software product.
• Archival of project metrics data.

  Swerefn
  refnum 001

• Software safety (if not addressed in the software safety plan).

  Swerefn
  refnum 271

• User notification of retirement.

  Swerefn
  refnum 209

• Decommissioning and disposal.

  Swerefn
  refnum 273

• The capture of Lessons Learned.

  Swerefn
  refnum 273

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 supports, maintenance, retirement activities.

  Swerefn
  refnum 273

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

Additionally, guidance related to operations, maintenance, and retirement planning may be found in 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 are not required to be in a separate document.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA 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

  Swerefn
  refnum 525

  :  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

  Swerefn
  refnum 526

  :  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

  Swerefn
  refnum 540

  : "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

  Swerefn
  refnum 543

  :  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

  Swerefn
  refnum 550

  : 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."  

6.2 Other Lessons Learned

Operations

• Ensure Ops procedures (production, test, launch/recovery, and mission) fully incorporate and/or reference applicable Ops Notes. Reinforce the use of written Op Procedures for work performed on vehicles in all operations.
• Establish minimum testbed configuration (required hardware in the loop) to support time-critical testing during missions and require appropriate control board approval for any deviations. The existence of hardware in the lab allowed critical issues to be identified during the OFT mission.
• Operation is a critical element of multi-level redundancy.

7. Software Assurance

7.1 Tasking for Software Assurance

1. Assess the plans for maintenance, operations, and retirement for completeness of the required software engineering and software assurance activities.

2. Confirm that the project implements software operations, software maintenance, and software retirement plans. 

7.2 Software Assurance Products

• Software Assurance Plan Assessment
• Software Engineering Plans Assessment
• Software assurance assessment of maintenance, operations, and retirement plans, including any issues or risks.

  
  

  Note
  title Objective Evidence
  Plan for the maintenance, operations, and retirement. Software assurance audit results for maintenance, operations, and retirement processes.

  Expand
  title Definition of objective evidence
  Include Page SITE:Definition of Objective Evidence SITE:Definition of Objective Evidence

7.3 Metrics

• # of software work product Non-Conformances identified by life-cycle phase over time
• # of Non-Conformances identified in plans (e.g., SMPs, SDPs, CM Plans, SA Plans, Safety Plans, Test Plans)

7.4 Guidance

Software assurance will assess the project’s plans for maintenance, operations, and retirement to judge the completeness and reasonableness of the plans for completing the software engineering and software assurance activities during those phases. The minimum recommended contents for the maintenance plan are found in the 7.18 - Documentation Guidance in this Handbook. The guidance for this section includes more details and considerations for topics that should be addressed in the maintenance plan. The contents listed for the maintenance plan also include the retirement plan. 

The operational documentation usually begins as a user manual and procedures and is typically created during implementation, sometime before system testing so the manual can be verified during this test phase for accuracy and completeness. At the beginning of the acceptance test phase, an updated version is supplied to the acceptance test team for evaluation. Corrections are incorporated and a final revision is produced at the end of the phase. For NASA flight project projects, the Software User Manual is baselined by the end of the Operational Readiness Review (ORR). 

A complete user manual contains a summary of the software; instructions for starting and using that software; a processing reference guide; assumptions, limitations, and safety information; and any information unique to this version of the software. The operational documentation should include all safety-related commands, data, input sequences, options, and other items necessary for the safe operation of the system. All error message descriptions and corrective actions need to be included in the operational documentation.  More information on the items contained in the user/operational document is contained in the 7.18 - Documentation Guidance in this Handbook under Software User Manual.

As operations continue and defects are found in the system, the operations instructions need to be updated with the latest information. This often includes the operational steps to perform a work-around for defects that have not yet been fixed or are not planned for repairs. Software assurance should verify that the detailed information for these workarounds and the operation of any safety-related activities have been included in the latest versions of the operations manuals.

As the project moves into maintenance and operations, software assurance needs to confirm that the operations and maintenance teams are following the documented plans and procedures for operations and maintenance. Process audits are useful in checking what is being done during these phases. For operations, it is key to determine whether the operator is following the correct procedures and instructions in the operations manual, particularly for the safety-related software. In maintenance, one of the most critical processes to assess is the process for testing defect fixes and then integrating the new versions into the operating system without any disruption to the normal operation of the software.

For retirement, software assurance will check to see that all the retirement plans have been followed. A few of the items that need to be considered and addressed are:

• All data from the project needs to be archived in a secure manner
• All operational software and support software need to be archived for potential future use
• All furniture and equipment need to be transferred to another group or excessed
• Computer equipment will also be transferred to another project or excessed—after removing all project information and archiving it
• All commercial software licenses need to be transferred or canceled
• Lessons learned from the project need to be completed and made available for other projects (Software assurance should capture their lessons learned.)
• The project manager or the contract technical point of contact will work with the contracting officer to close out any project-specific contracts.