bannerc
SWE-075 - Plan Operations, Maintenance, Retirement

1. Requirements

4.6.2 The project manager shall plan and implement 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 History

SWE-075 - Last used in rev NPR 7150.2D

RevSWE Statement
A

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

Difference between A and BAdded requirement to implement.
B

4.6.2 The project manager shall plan and implement software operations, maintenance, and retirement activities.

Difference between B and C

No change

C

4.6.2 The project manager shall plan and implement software operations, maintenance, and retirement activities.

Difference between C and DNo change
D

4.6.2 The project manager shall plan and implement software operations, maintenance, and retirement activities.



1.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable

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

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. 001
  • Test of ground displays and software during mission sequence tests or other end-to-end tests. 001
  • Performance assessments, as applicable. 273
  • Training for replacement operators and maintainers. 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. 001
  • Maintenance transition plan.
  • Software assurance and software safety activities for updates.
  • Corrective maintenance for software defects. 001
  • Adaptive maintenance for "software changes necessitated by other changes, usually to the hardware." 001
  • Changing requirements maintenance. 001
  • Operational data maintenance to support system configuration changes needed to use the software. 001
  • Maintenance after new revisions of the software is released.
  • User notification of updates. 209

Retirement

  • Archival of software products, including capture in configuration management (CM) system. 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. 001
  • Software safety (if not addressed in the software safety plan). 271
  • User notification of retirement. 209
  • Decommissioning and disposal. 273
  • The capture of Lessons Learned. 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. 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 276. 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.

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

NASA-specific operations, maintenance, and retirement information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.

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

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

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

SWE-075 - Plan Operations, Maintenance, Retirement
4.6.2 The project manager shall plan and implement software operations, maintenance, and retirement activities.

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.


    Objective Evidence

    • Plan for the maintenance, operations, and retirement.
    • Software assurance audit results for maintenance, operations, and retirement processes.

    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

  • # 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.


  • No labels