Module SEO01 Software Evolution

1
Module SE-O-01Software Evolution
Topic 5 Managerial Aspects of Software Evolution
2
Contents

• Introduction
• Cost Estimation
• Change Prediction
• Change Impact Analysis
• Effort Estimation

3
Managerial aspects of software evolution

• Predicting evolution
• Cost and effort estimation
• Change prediction and change impact analysis
• Change metrics
• Change management
• Version management
• Software configuration management

4
Contents

• Introduction
• Cost Estimation
• Change Prediction
• Change Impact Analysis
• Effort Estimation

5
Cost Estimation Development vs maintenance costs

• Maintenance costs
• are usually greater than development costs
• factor 2 to 100 depending on the application
  (domain)
• are affected by both technical and non-technical
  factors
• technical e.g. hardware, OS, interaction with
  other systems
• non-technical e.g. volatile requirements,
  management decisions
• increases as software is maintained
• maintenance corrupts the software structure so
  makes further maintenance more difficult
• evidence Law 2 (increasing complexity) Law 6
  (continuing growth) Law 7 (declining quality)
• Legacy software can have high maintenance costs
• old languages (e.g. Cobol), old compiler
  versions, etc.

6
Cost Estimation Development vs maintenance costs

• (taken from Sommerville)

7
Cost Estimation Development vs maintenance costs

• External factors affecting maintenance cost
• Team stability
• Maintenance costs are reduced if the same staff
  are involved with them for some time
• Contractual responsibility
• If the software developers have no contractual
  responsibility for maintenance, there is no
  incentive to design for future change, resulting
  in poorly structured software
• Staff skills
• Maintenance staff are often inexperienced and
  have limited domain knowledge (e.g. novice
  programmers)
• Program age and structure
• As programs age, their structure degrades and
  becomes harder to understand and modify (cf.
  evolution laws)

8
Contents

• Introduction
• Cost Estimation
• Change Prediction
• Change Impact Analysis
• Effort Estimation

9
Change Prediction

• Change prediction is concerned with assessing
  which parts of the system may cause problems and
  have high maintenance costs
• Change acceptance depends on the effort required
  to modify the components affected by the change
• Requires techniques such as
• Impact analysis
• to predict which components will be affected by
  the change
• Effort estimation
• to predict the effort it will take to modify
  these components
• depends on the "quality" of these components
• Cost estimation
• to predict the total cost to implement the change

10
Change Prediction

• (taken from Sommerville)

11
Change Prediction

• Problem Software engineers are louzy in
  predicting which classes will change upon
  evolution
• Empirical study of LindvallSandahl1998 only
  between 30 and 40 of actual changed classes
  were predicted to be changed!
• Need for a more objective approach for
  identifying evolution-prone parts of a software
  system
• e.g. software metrics

12
Change Prediction Software Metrics

• Software metrics can be helpful as an objective
  measure to predict the impact of changes
• Different types of software metrics are available
• Coupling and cohesion metrics
• High cohesion between components and low coupling
  among components are design principles aimed to
  reduce the system complexity, and as such,
  increase its maintainability
• A lower coupling between components implies a
  lower impact of changes
• A higher cohesion of a component increases its
  understandibility
• Complexity metrics
• More complex components are more difficult to
  modify
• Process metrics
• May be used to measure maintainability

13
Change Prediction Software Metrics

• Complexity metrics
• Predictions of maintainability can be made by
  assessing the complexity of system components
• Studies have shown that most of the maintenance
  effort is spent on a relatively small number of
  system components
• Complexity depends on
• Complexity of control structures
• e.g. McCabe's Cyclomatic Complexity
• Complexity of data structures
• Object, method (procedure) and module size

14
Change Prediction Software Metrics

• Process metrics
• may be used to assess maintainability
• Examples
• Number of outstanding change requests
• Number of requests for corrective maintenance
  (bug fixes)
• Average time required for impact analysis
• Average time taken to implement a change request
• An increase in any or all of these may indicate a
  decreased maintainability

15
Change Prediction Software Metrics

• Cohesion metrics
• measure the degree to which elements of a
  component belong together
• two categories of cohesion metrics
• based on structural cohesion
• define and measure structural relationships among
  elements belonging to the same component
• based on logical (or semantic) cohesion
• do the elements of a component logically/functiona
  lly/semantically belong together?

16
Change Prediction Software Metrics

• OO cohesion metrics measure the degree to which
  methods of a class belong together
• metrics based on structural cohesion
• the degree of cohesion depends on the number of
  pair of methods that share or reference the same
  variables
• examples
• LCOM (lack of cohesion in methods)
• TCC (tight class cohesion)
• LCC (loose class cohesion)
• ICH (information-flow-based cohesion)
• metrics based on logical (or semantic) cohesion
• requires domain knowledge or natural language
  processing
• examples
• LORM (logical relatedness of methods)

17
Change Prediction Software Metrics

• Coupling metrics
• measure the degree of interdependence between
  pairs of components
• examples of OO coupling metrics
• CBO (coupling between object classes)
• measures the number of other classes to which a
  given class is coupled Change Impact Analysis

18
Contents

• Introduction
• Cost Estimation
• Change Prediction
• Change Impact Analysis
• Effort Estimation

19
Change impact analysis

• Definition BohnerArnold 1996
• The activity by which the programmers assess the
  extent of a change, i.e., the components that
  will be impacted by the change.
• Change impact analysis indicates how costly the
  change is going to be (cf. effort estimation) and
  whether it is to be undertaken at all.

20
Change impact analysis

• Predicting the number of changes requires an
  understanding of the relationships between a
  system and its environment
• Tightly coupled systems require changes whenever
  the environment is changed
• Low coupling implies a lower change impact
• Factors influencing this relationship are
• Number and complexity of system interfaces
• Number of inherently volatile system requirements
• The business processes where the system is used

21
Change impact analysis

• Ripple effect!

Changing a component
Change propagation
22
Change impact analysis

• Ripple effect Yau 1978
• the phenomenon where a change in one piece of a
  software system affects at least one other area
  of the same software system (either directly or
  indirectly).
• Change propagation Rajlich 1997
• occurs when making a change to one part of a
  software system requires other system parts that
  depend on it to be changed as well. These
  dependent system parts can on their turn require
  changes in other system parts. In this way, a
  single change to one system part may lead to a
  propagation of changes to be made throughout the
  entire software system.

23
Change impact analysis change propagation

• visit components one-by-one
• if the visited component is modified, it may no
  longer fit
• secondary changes must be made in interacting
  (neighboring) components
• secondary changes may trigger additional changes
• ripple effect
• software is inconsistent during propagation
• hidden propagation
• class itself does not change but propagates
  change

24
Contents

• Introduction
• Cost Estimation
• Change Prediction
• Change Impact Analysis
• Effort Estimation

25
Effort Estimation

• It is important for managers to
• estimate amount of effort and related schedule
  required for accomplishing software evolution
  tasks
• assess programming productivity
• detect productivity decreases due to software
  aging or increase of software complexity
• need for restructuring or replacing the software
  system
• detect productivity increases due to more
  programmer experience or process improvements

26
Effort Estimation ctd.

• Effort estimation in the context of software
  evolution not thoroughly treated in the
  literature
• Only in the context of software development from
  scratch there are some approaches available, but
  results are not transferable to the context of
  software evolution
• Notable exception LehmanRamil2000
• Evolution of a mainframe operating system kernel
  (IBM 360) over 17 years of its lifetime
• Effort estimation model with an accuracy of appr.
  20