2.6 Software maintenance  (Page 8/10)

Unique activities

There are a number of processes, activities, and practices that are unique to software maintenance, for example:

• Transition: a controlled and coordinated sequence of activities during which software is transferred progressively from the developer to the maintainer.
• Modification Request Acceptance/Rejection: modification request work over a certain size/effort/complexity may be rejected by maintainers and rerouted to a developer.
• Modification Request and Problem Report Help Desk: an end-user support function that triggers the assessment, prioritization, and costing of modification requests.
• Impact Analysis.
• Software Support: help and advice to users concerning a request for information (for example, business rules, validation, data meaning and ad-hoc requests/reports).
• Service Level Agreements (SLAs) and specialized (domain-specific) maintenance contracts which are the responsibility of the maintainers.

Supporting activities

Maintainers may also perform supporting activities, such as software maintenance planning, software configuration management, verification and validation, software quality assurance, reviews, audits, and user training.

Maintenance planning activity

An important activity for software maintenance is planning, and maintainers must address the issues associated with a number of planning perspectives:

• Business planning (organizational level)
• Maintenance planning (transition level)
• Release/version planning (software level)
• Individual software change request planning (request level)

At the individual request level, planning is carried out during the impact analysis. The release/version planning activity requires that the maintainer:

• Collect the dates of availability of individual requests
• Agree with users on the content of subsequent releases/versions
• Identify potential conflicts and develop alternatives
• Assess the risk of a given release and develop a back-out plan in case problems should arise
• Inform all the stakeholders

Whereas software development projects can typically last from some months to a few of years, the maintenance phase usually lasts for many years. Making estimates of resources is a key element of maintenance planning. Those resources should be included in the developers’ project planning budgets. Software maintenance planning should begin with the decision to develop a new system and should consider quality objectives (IEEE1061-98). A concept document should be developed, followed by a maintenance plan.

The concept document for maintenance should address:

• The scope of the software maintenance
• Adaptation of the software maintenance process
• Identification of the software maintenance organization
• An estimate of software maintenance costs

The next step is to develop a corresponding software maintenance plan. This plan should be prepared during software development, and should specify how users will request software modifications or report problems. Software maintenance planning is addressed in IEEE 1219 and ISO/IEC 14764. ISO/IEC14764 provides guidelines for a maintenance plan.