maintenance - ida.liu.setddd30/timetable/maintenance.pdfdefinition of maintenance all changes done...
TRANSCRIPT
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