Maintenance

Basic concepts

Definition of maintenance

All changes done to software after delivery (IEEE Std 1219) Modifications due to a problem or need of improvement

(IEEE/EIA Std 12207) What about products in different releases over a long period?

Categories of maintenance

Correction Enhancement

Proactive Preventive Perfective

Reactive Corrective Adaptive

0%

10%

20%

30%

40%

50%

60%

Cost

PerfectiveAdaptiveCorrective

ProcessChange request

Identification

Classification

Time stamp

Impact analysisUnderstanding

Requirementsanalysis

Design

Implementation

Tests at different levels

Configurationmanagement

Delivery

Scheduling

Postponed

Refused

Decision

Answer

Hypothesis-Driven Understanding Process During Corrective Maintenance of Large Scale Software

byAnneliese von Mayrhauser

andA. Marie Vans

International Conference on Software Maintenance, October 1-3, Bari, Italy, 1997.

Theory

A Goal or Question drives the process of understanding They can be explicit or implicit According to a certain Strategy, Hypothesis are formed A Strategy can be: Systematic Opportunistic Cross-referencing

Design of study

Four professional programmers Software at least 40 KLOC 2 hour video/audio recording Think aloud Corrective maintenance Transcription Coding: Actions: stating a goal, stating a hypothesis, supporting actions X

program, top-down (domain), situation (algorithm) Hypothesis type: what, why, how Resolution: confirmed, abandoned, rejected

Type of hypotheses

Domain level: most in localising faults, procedure/function concepts, environment and tools

Program model: statement execution order, code correctness, variable

Situation model: functionality at procedure level (abstracted from program)

Types: few Why (attitude: I’ll do my part?)

Hypothesis resolution

Surprisingly many abandoned Explanation: Flexible in approach to comprehension ”Arsenal” approach

Earlier study in porting programs generated fewer hypotheses (38/51). More things unknown in corrective maintenance.

Hypothesis switching

More than half of hypotheses caused a switch Confirms the belief that the situation model is a bridge between

top-down model and program model

Dynamic resolution process

Within area of expertise: Many abandoned hypotheses Large steps ”Arsenal” behaviour

Outside expertise: Hard to abandon hypotheses Small steps

Conclusion

Corrective maintenance has a need to understand software at all levels

There is lot of switching between levels Goal completion is sequential. Support cross-referencing Support flexible starting points

Method for improvement by understanding the dynamic behaviour in distributed systems

By Johan Moe

Applications

Toolbox

Visualisation

Traceability

analysis design implementation

Benefits from good traceability

Fulfilment of requirements can be assured Design rationale can be sought in affected requirements Change impact analysis forwards and backwards Cost estimations are made possible System understanding becomes easier Maintenance and testing are facilitated

Practical investigation in traceability

From Lindvall and Sandahl: Practical Implications of Traceability, Software – Practice and Experience, 26(10), 1161-1180.

Conducted at Ericsson’s PMR project Example of successful project Method and tool: Forward engineering, Objectory SE (forerunner of

UML and IBM Rational Updating of models was emphasised by the project leader

Are these the same models?

Three-to-one traceability

Tracing non-functional requirements in models

Elicitation

Analysis

Design

#subscribers#messages

#managedObjects#invocations

#instances#bps

Use Case

State

Class

Interaction

Deployment

UML Diagrams

Capacity Budget:Use Case may use X% CPUMax latency given throughput requirement

Design for maintenance

Configuration management Change control Identify change-prone properties Factor out parameters Explicitly handle rules and equations

Low coupling High cohesion Low McCabe complexity