Software Maintenance: A Tutorial by Keith H' Bennett

1
Software Maintenance A Tutorialby Keith H.
Bennett

• IEEE Computer Society Press, 1997
• Presentation by JIN LYU
• 2/23/2004

2
Overview

• Problem/Solution categories
• Organizational issues
• Process issues
• Technical issues
• Maintenance is an iterative process
• Legacy system a software that is too
  difficult and expensive to maintain and requires
  drastic action.

3
Software Engineering Field

• Main problem of software engineering
• Scale and Complexity of the software
• Goal of software maintenance
• Software system should be
• Delivered on time
• Fully meet requirements
• Applicable in safety critical systems

4
Software Maintenance

• Definition
• Process of modifying software system or
  component after delivery to correct faults,
  improve performance or other attributes, or adapt
  to a change in environment
• 4090 of total life cycle costs according to
  surveys
• Applications backlog occurs when unable to
  undertake maintenance quickly, safely and cheaply
  required by business needs/marketing

5
History of maintenance

• Early decades - new applications development
• Late 1960s and 1970s software maintenance
  started to be recognized as a significant
  activity
• 1980s Old architecture is difficult to maintain
  in order to meet new requirements
• 1990s Evolutionary change of software and
  development is enhancement and evolution

6
Types of Software Maintenance

• Perfective maintenance changes required as a
  result of user requests.
• Adaptive maintenance changes needed due to
  change of OS, hardware or DBMS
• Corrective maintenance the identification and
  removal of faults in software
• Preventative maintenance changes made to
  software to make it more maintainable
• Majority of maintenance is perfective maintenance

7
Requirements of maintenance

• Quickly accomplished
• Cost Effective
• Reliability should not be degraded
• Maintainability should not be degraded future
  change will become more expensive
• Laws of evolution by Lehman
• Ultimately maintenance will be almost infeasible
  and software becomes legacy system

8
Law of evolution

• 1st law a program that is used in a real world
  environment necessarily must change or become
  progressively less useful in that environment.
• 2nd law as an evolving program changes, its
  structure tends to become more complex. Extra
  resources must be devoted to preserving the
  semantics and simplifying the structure.

9
Problems of software maintenance

• Domino or ripple effect change in source code
  may cause substantial changes to documentation,
  design and test suites.
• 3 categories of maintenance problems
• Alignment with organizational objectives
• Process issues
• Technical issues

10
Alignment with organizational objectives

• Maintenance is viewed by senior management as a
  major activity consuming large resources without
  clear quantifiable benefit for organization

11
Process Issues

• Initial requests for changes
• Impact analysis on both the software and
  organization, cost analysis, need for system
  comprehension
• Regression test to prevent introducing errors
  when software is altered

12
Technical Issues

• Building an easily comprehensible software
• Majority of time spent on this activity in
  maintaining
• Testing in a cost effective way
• Test sub-set that has been changed rather than
  full system
• perform regression tests

13
Other issues

• Cost cutting in design in development process
  negatively effects costs of maintenance
• Little incentive for management to develop a
  easily evolvable software

14
Organizational Aspects

• Major problem of software maintenance is
  managerial
• Maintenance is regarded as drain on resources,
  non-profit generator
• Maintenance suffers from low investment and poor
  status
• Trend for maintenance to be outsourced

15
Service level agreements

• Contractual mechanism for defining maintenance
  service to be provided
• Repair of errors on delivery
• Vendor pays to correct problem
• Changes to reflect ambiguous specification
• Difficult to resolve and address

16
Software as an asset

• Proposed by Foster in 1993, also used in Japan
• Ensures maintenance has a high profile and
  justifies financial support
• Allows maintenance manager to assess the
  financial implication of change to calculate cost
  and benefit
• COCOMO techniques, AMES project to aid
  application management

17
Process Models

• Process management the direction, control and
  coordination of work performed to develop a
  product or perform a service.
• Software process model needs well understood
  mature processes
• Assess maturity of an organization
• Provide metric for process improvement

18
IEEE Standard for software maintenance (1994)

• Iterative approach, differentiate development
  process and maintenance.
• Four key stages
• Help Desk preliminary analysis of problem
  received to determine sensibility
• Analysis choose solution after managerial and
  technical analysis
• Implementation implement chosen solution
• Release change is released to customer

19
Overview of IEEE standard for software maintenance

• 7 stage activity model
• Problem Identification
• Analysis
• Design
• Implementation
• System Test
• Acceptance Test
• Delivery

20
Overview continued

• Each of the seven activities has 5 associated
  attributes
• Input life cycle products
• Output life cycle products
• Activity definition
• Control
• Metrics

21
Overview continued 2..

• 2nd stage Analysis is the most difficult and
  crucial
• Feasibility analysis
• Determine requirements of modification, required
  tools, test strategy implementation plan
• All affected components are identified
• test strategy for three levels and regression
  test requirements are developed
• Unit testing, integration testing, functional
  acceptance testing

22
More on standard

• Provides minimum processes to ensure quality
  control for each phases
• Pg 477 provide example for analysis stage.
• Based on classical concepts of software
  development
• Does not cover rapid application development,
  end-user computing, and executive level issues
• Corresponds to level 2 in SEI five level model

23
Technical aspects of software maintenance

• Required technology is similar to initial
  development with minor changes
• Impact analysis is needed for maintenance
• Translation of user expressed problems into
  software terms to decide viability of problem
• Identify primary components to be altered
• Investigate alternate solutions
• Determine best solution based on result of impact
  analysis

24
Technical problems

• Ripple effect
• changes made to a software component have a
  tendency to be felt in other components
• Static Analysis and dynamic analysis are used
• Impact Analysis identifies further objects
  impacted by changes until no further objects can
  be identified.

25
Traceability

• Provide semantic links that can be used to
  perform impact analysis
• Some links are hard to determine
• Most impact analysis is done at code level
• Documentation is modeled using a ripple
  propagation graph for analysis
• Allows analyze assess costs without reference to
  code
• Research that allows transformation of
  specifications to executable code and vice versa
  are underway (1995)

26
Legacy Systems

• No formal definitions
• Very old system that has been heavily modified
• Usually large scale
• written in obsolete language
• no documentation
• large quantities of live data are utilized by
  system
• still functional
• hard to meet growing needs
• expensive to replace
• Most software today will end up as legacy
  software in 20 years.

27
Analysis of legacy systems

• Various solutions to deal with legacy systems are
  given in pg 480
• Reverse Engineering approach
• Might be most fruitful approach
• Encapsulation approach are getting popular
• New system is evolved so that it will
  progressively takes over functionality from old,
  until the latter becomes redundant

28
Reverse Engineering

• Definition
• The process of analyzing a subject system to
  identify the systems components and their
  inter-relationships, and to create
  representations of the system in another form or
  at higher levels of abstraction
• Passive
• does not change the system nor produce new system
• Provide help in program comprehension
• Two types
• Re-documentation
• Design recovery

29
Methods of reverse engineering

• Slicing
• Static analysis technique
• Only the source code that affect a nominated
  variable are examined
• Tools to attach notes the the source code
• Avoid re-documentation of whole system
• Stable part of code are not studied
• Cost saving

30
More on legacy systems

• Program comprehension
• Restructuring active change of legacy system
• Transformation from one representation to another
  at same relative level of abstraction
• Preserves systems external behavior
• increase maintainability
• Re-engineering
• The examination and alternation of the subject
  system to reconstitute it in a new form
• Most radical and expensive

31
Criteria for reverse engineering

• List of criteria on pg 481-482
• Management criteria
• Quality criteria
• Technical criteria
• Analysis should start with business rule
  contained in legacy systems
• legacy system represents accumulated experience
• Does actual high level, coherent representation
  exists?
• Need to discover current system model

32
Reverse Engineering Techniques

• Use of control flow and data flow graphs
• Restructure of control flow
• Commercial tools are available to support
  maintenance
• Program plan or cliché approach
• Majority of program uses generic design ideas
• Matching generic design patterns in source code
  from library

33
Techniques continued

• Source language independent approach
• Design of intermediate languages (UNIFORM, WSL)
• Different languages are handled by adding front
  ends
• Discovery of abstract data types in existing code
  using tools

34
The end..

• Any thoughts???