Software Maintenance

Software Maintenance

prepared February 23, 2009

Slides by Topic

  • Preliminaries
  • Significance of Maintenance
  • What is Maintenance?
  • Kinds of Maintenance
  • Maintenance Process
  • Side Effects
  • Preliminary Evaluation
  • Feasibility Study
  • Classify Maintenance Request
  • Personnel Factors
  • Availability of Material
  • Quality of Previous Work
  • Impact of System Design
  • Quality Design Implies Maintainability
  • Begin with Design
  • Reverse Engineering
  • Maintaining "Alien Code"
  • Rules of Thumb"
  • Danger Zones
  • Other Considerations
  • Laws" of Program Evolution
  • Dealing with Managers

  • Significance of Maintenance

    Maintenance is the single most costly phase of the software product life cycle.

    Estimates run from 20% to 75% of total cost, mostly toward the top of this range.

    Maintenance is the ``software iceberg'',

    except that it grows rather than melts.

    Maintenance seems especially difficult.

    Productivity reduction by a factor of 40 has been reported!

    - Boehm, 1979


    What is Maintenance?

    When the life-cycle steps are applied to an existing program, this is called maintenance.

    However, there is often ambiguity about when a change in requirements initiates a new product life-cycle rather than merely maintenance.


    Kinds of Maintenance

    * Corrective < 25%

    fix errors

    * Adaptive < 25%

    respond to changes in systems environment - operating system, utility software, other applications, etc.

    * Preventative e

    improve future maintainability & reliability
    """technology retirement"""

    * Supplementative > 50%

    enhance, respond to requirements changes
    often called ``perfective''


    Maintenance Process

    Maintenance should

    * be requirements- and design-driven, just like the original development process

    * follow similar life-cycle

    * apply similar process controls


    Side Effects

    Problem of side effects especially severe in maintenance activities.

    Side effects may impact:

    * code execution (traditional side effect)

    * code structure

    * system architecture

    * data representation

    * data values

    * process

    * documentation


    Feasibility Study

    Environmental concerns especially important

    Evaluate:

    * request itself

    * staff carryover

    * material carryforward

    * quality of preceeding process

    * characteristics of developed products


    Classify Maintenance Request

    * corrective
    (error)

    * is error frequent?

    * is error costly?

    * is error isolated?

    * adaptive
    (environment change)

    * is change within organization?

    * is change localized?

    * supplementative/preventative
    (enhancement)

    * is change mandatory

    * is enhancement well-defined?

    * does enhancement provide significant return?


    Personnel Factors

    * As in all software projects, availability of qualified staff is the dominant factor

    * Presence of members of the original design team helps immensely

    * knowledge of product

    * knowledge of domain

    * knowledge of process
    configuration and integration tricks testing, verification & validation


    Availability of Material

    source code

    * without question

    testing materials

    * test plans

    ! test cases
    regression testing

    design documents

    * essential, although we might pretend otherwise

    requirements analysis & specification

    o provides coherence

    * generate test cases if missing


    Quality of Previous Work

    * understandability of system design

    * standardization of programming tools

    * standardization of documentation

    «Design documentation that doesn't accurately reflect the current state of software is probably worse than no documentation at all.»

    - Pressman, 1992


    Quality Design Implies Maintainability

    * The most important factor for easy maintenance is a maintainable product

    * Cannot begin a structured software process starting with an unstructured system

    * One measure estimates maintenance effort increases exponentially in """complexity attributed to poor design and documentation."""

    => design
    => documentation


    Begin with Design

    Process should be design-based

    * Terrible!

    expand this figure

    * Unwise - avoid if at all possible

    expand this figure

    * Recommended

    expand this figure


    Reverse Engineering

    Main goal is design recovery, but the recovered information is often at too low a level of abstraction.

    Useful for

    * recovering and comparing file organizations

    * program (code) restructuring

    Useful as programmer's aide on a large project.


    Rules of Thumb"

    1. Study program before entering """emergency mode."""

    2. Become familiar with overall structure, avoiding details.

    3. Evaluate existing documentation; diagram and comment if needed.

    4. Make good use of cross references and other aids.

    5. Make changes with utmost caution.

    6. Don't eliminate code unless your sure it isn't used.

    7. Declare your own variables rather than reusing.

    8. Keep detailed records of activities and results.

    9. Temper the urge to throw program away and rewrite it.

    10. Insert error checking & diagnostics.

    - Yourdan, 1975


    Danger Zones

    1. a subprogram is deleted or changed

    2. a statement label is deleted or modified

    3. an identifier is deleted or modified

    4. changes are made to improve execution performance

    5. a file open or close is modified

    6. logical operators are modified

    7. design changes are translated into major code changes

    8. changes are made to logical tests of boundary conditions

    - Freedman & Weinberg, 1990


    Laws" of Program Evolution

    Continuing change - program must change or become less useful

    Increasing complexity - structure of evolving program becomes more complex unless active efforts are made

    Large program evolution - program evolution is a self-regulating process with statistically significant [local] trends and invariances

    Organizational stability - over the lifetime of a program, rate of [change] is approximately constant independent of resources

    Conservation of familiarity - incremental system change approximately constant from release to release

    - Lehman & Belady, 1985


    Dealing with Managers

    Maintenance causes most severe political stresses because it:

    * is urgent

    * has unanticipated resource requirements

    * needs unanticipated managerial attention