Kristian Sandahl, IDA
krisa@ida.liu.se
Metrics count: number, date of arrival etc.
Scheduling
Decision (accept, reject, further evaluation)
Prioritisation
Classification
Unique identification
7 steps:
Problem identification
Analysis
Design
Implementation
System test
Acceptance test
Delivery
Driven by Modification
Request (MR)
Output new baseline (≈
approved product)
Problem identification
IEEE maintenance model
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
“The modification of a software product after
delivery to correct faults, to improve performance
or other attributes, or to adapt the product to a
modified environment”
IEEE-STD 1219
Goal:
Types of maintenance
Maintenance process
Experimentation in
software engineering
Design for Maintainability
Research in Linköping
Code understanding
About 70% of all software costs!
Definition
Changing software
0%
10%
20%
30%
40%
50%
60%
Cost
Feasibility
Impact analysis
Cost estimation
Benefits
Requirements formulation
Safety and security impact analysis
Test strategy
Plan
Analysis
maintenance
Perfective maintenance
Adaptive
Corrective maintenance
Preventive maintenance
Classification
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Perfective
Adaptive
Corrective
Assessment and Assimilation (0-8)
Software Understanding (10-50)
0.4 * percentage of changed design
0.3 * percentage of changed code
0.3 * percentage of integrated external code
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Instrumentation:
avg number of probe points
Self-descriptiveness
Readability: 0.295*avg var length+0.499*statement
lines+0.13V(G)
avg methods per class / avg lines of code per class
Modularity:
Cyclomatic number (McCabe(1976)): V(G) = e – n + 2p
Complexity:
Effort = number of staff months
C1 = scaling constant
EAF = Effort Adjustment Factor
Size = number of delivered, human produced
source code instructions (KDSI)
P1 = exponent describing the scaling inherent of
the process (0.91-1.23)
Effort = C1 EAF (Size)P1
Kristian Sandahl, IDA
krisa@ida.liu.se
Boehm et al: Predict maintenance size:
Size = ASLOC *0.01*
Follow up impact analysis
Update design model
Acceptance testing
Metrics
Update implementation model
Test cases
System testing
Effort
Unit test
Verification of requirements
Testing
Maintainability
Code
Design
Kristian Sandahl, IDA
krisa@ida.liu.se
Implementation
Design
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
design
class
method
method
method
class
method
method
method
few
many
class
method
method
method
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
implementation
class
method
method
method
Coupling and cohesion
analysis
Traceability
unnecessary correct
predicted
wrong
actual
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Underprediction
Underpredictionfactor
factor1,5
1,5- -66
Lindvall
Lindvall&&Sandahl:
Sandahl:
Case-study
Case-studyPMR:
PMR:Kristian Sandahl, IDA
Research: Impact analysis
High cohesion
Low coupling
Identify change-prone properties
Factor out parameters
Explicitly handle rules and equations
Low McCabe complexity
Corba object
1
Corba object
5
Corba object
2,3,4
krisa@ida.liu.se
Statistics
Kristian Sandahl, IDA
Trace log
Visualistation
Corba object
6
Corba object
Research: Tracing system
dynamics
Kristian Sandahl, IDA
krisa@ida.liu.se
Equation:
working week = 38.75 h
Rule:
if permanently employed and
more than three years
before retirement
then offer home-PC
Instead of:
plot(145,150)
plot(163, 300)
Write:
y:=150
plot(145, y)
plot(163, y*2)
Configuration management
Change control
Change-prone properties
Design for maintenance
Present
results
Summarise
statistics
activity
tool
mechanism
Operational
profiles
Observation
Coverage
Active probing
Built on
Simulation
Uses
Testing
Testing Usage
System
evaluation
Evaluation Tuning
Applications
test suites
A user can change
the observed
system or
prototyping, test
or operation
A user activates
observation or/and
simulation during
Collect
data
By Johan Moe
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Method for improvement by understanding the
dynamic behaviour in distributed systems
Parser
Parser
Kristian Sandahl, IDA
krisa@ida.liu.se
International Conference on Software Maintenance, October
1-3, Bari, Italy, 1997.
by
Anneliese von Mayrhauser
and
A. Marie Vans
Kristian Sandahl, IDA
krisa@ida.liu.se
Trace sequences
(Correct/non correct)
Statistics
Hypothesis-Driven Understanding Process During
Corrective Maintenance of Large Scale Software
Raw traces
(txt)
Log
Logserver
server
Observation
Observation
Toolbox
Kristian Sandahl, IDA
krisa@ida.liu.se
Systematic
Opportunistic
Cross-referencing
Kristian Sandahl, IDA
krisa@ida.liu.se
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:
Theory
Visualisation
Kristian Sandahl, IDA
krisa@ida.liu.se
bridge between top-down model and program
model
Hard to abandon hypotheses
Small steps
Outside expertise:
Many abandoned hypotheses
Large steps
”Arsenal” behaviour
Within area of expertise:
Confirms the belief that the situation model is a
More than half of hypotheses caused a switch
Kristian Sandahl, IDA
krisa@ida.liu.se
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
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
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?)
Domain level: most in localising faults,
Dynamic resolution process
Four professional programmers
Software at least 40 KLOC
2 hour video/audio recording
Think aloud
Corrective maintenance
Transcription
Coding:
Type of hypotheses
Hypothesis switching
Design of study
Flexible in approach to comprehension
”Arsenal” approach
Support flexible starting points
Support cross-referencing
Goal completion is sequential.
There is lot of switching between levels
understand software at all levels
Corrective maintenance has a need to
Conclusion
hypotheses (38/51). More things unknown in
corrective maintenance.
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Earlier study in porting programs generated fewer
Explanation:
Surprisingly many abandoned
Hypothesis resolution