Software Rejuvination

Definitions

Software Rejuvination

an architectural mechanism in which an application or software component gracefully terminates execution and immediately restarts it in a known, clean, internal state.

Discussion

Applications and software components often suffer from random and transient failures due to latent defects that are just too costly to find and fix (a.k.a., Heisenbugs named after Werner Heisenberg’s uncertainty principle). The associated failures often show up only after a significant amount of execution time, and they are typically due to such defects as memory leakage, unreleased file lockage, and data corruption. They often prevent an application or component from achieving its operational availability requirements and reliability requirements. A way is needed to allow the defects to remain in the application and software components, while simultaneously preventing the associated failures from occurring.

Objectives

The typical objectives of software rejuvination are to:

• Anticipate and avoid failures.
• Increase operational availability and reliability by minimizing failure due to latent defects that are too expensive to find and fix.
• Minimize testing costs.

Description

Software rejuvination can typically be described as follows:

• Software is designed, programmed, and tested to gracefully terminate an application and immediately restarts it in a known, clean, internal state.
• Termination and restart may be global or on a process by process basis.

Stakeholders

The typical stakeholders of the software rejuvination mechanism are:

• Producer: Architecture Team
• Evaluator: Architecture Inspection Team
• Approvers:
  • Technical Leader
  • Project Manager
  • Customer Representative
• Maintainer: Architecture Team
• Users:
  • Teams:
    • Architecture team, which uses it as an input when producing the software architecture document.
    • Software development team, which uses it as an input when producing the software architecture prototype and to drive the design of the software.
    • Independent test team, which uses it as an input when generating operational availability test cases.
  • Organizations:
    • Customer organization, which uses it to minimize costs and to understand how operational availability and reliability requirements will be met.
    • Maintenance organization, which benefits from the decreased need to perform manual perfective and preventative maintenance.
    • User organization, which benefits from the increase in operational availability and reliability.

Phases

The software rejuvination mechanism is typically developed during the following phases:

• Business Strategy: Not Applicable
• Business Optimization: Not Applicable
• Initiation: Completed.
• Construction: Maintained.
• Delivery: Maintained
• Usage: Maintained
• Retirement: Archived

Preconditions

The software rejuvination mechanism can typically be started if the following preconditions hold:

• The initiation phase has started.
• The architecture team has been staffed and trained in architecture mechanisms.
• A initial system requirements specification containing a significant number of the architecturally significant operational and quality requirements is available.

Inputs

The typical inputs to the software rejuvination mechanism include:

• Work Products:
  • System Requirements Specification for architecturally significant requirements
• Stakeholders:
  • TBD

Limitations

Software rejuvination is typically subject to the following limitations:

• If high operational availability is required, then software rejuvination requires redundant hardware that can continue execution execution while individual processes can be stopped and restarted.
• Software rejuvination increases execution overhead.
• Software rejuvination does not eliminate the underlying defects; it merely allows the application or component to avoid the associated failures.

Guidelines

• Software rejuvination is a form of automated preventative self maintenance.
• It is important to identify the optimal interval between successive applications of software rejuvination so as to balance the risk of failure due to the cost of performing the preventative maintenance.

---

---

---