Software Change

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron


  • Many of the following slides are adapted from the slides for the book “Software Engineering: The Current Practice” by Vaclac Rajlich © 2012 by Václav Rajlich

Software Change

  • software change (SC) is the process of adding new functionality to existing code
  • Foundation of
    • software servicing
    • software evolution
    • agile processes

Change Categories (LST’78)

  • perfective - user enhancements, improved documentation, recoding for computational efficiency
  • adaptive - accommodation of changes to data inputs and files and to hardware and system software
  • corrective - emergency fixes, routine debugging
  • other
  • Lietz, Swanson, Tompkins’78

Change Distribution

Category Manager Work Est. (LST'78)
Adaptive 18.2%
Corrective 17.4%
Perfective 60.3%
Other 4.1%

Change Distribution

Category Manager Work Est. (LST'78) Change-log (Schach,et al'03)
Adaptive 18.2% 2.2%
Corrective 17.4% 56.7%
Perfective 60.3% 39.0%
Other 4.1% 2.4%



  • incremental adding new functionality
  • contraction removing obsolete functionality
  • replacement replacing existing functionality
  • refactoring changing the structure of software without changing behavior


  • change a local variable name
  • change the name of a parameter
  • Move from std::map to QMap (Qt)
  • Remove networking API
  • Change to new language/compiler version

Impact Levels

  • local - effects only small, immediate part of code, i.e., individual method, class, or small namespace/package
  • significant impact - effects more than one part of the code, or very scattered parts of the code
  • massive impact - change to an entire system

Management issues

  • Decision to make the change
  • Decision on how to make the change
    • Change that improves structure, comprehension, etc. of program
    • A quick fix, kludge, quick-and-dirty

Form of Changing Code

  • Source-code level
  • Code after compilation
    • object
    • executable - Includes “wrapper” technique

Main Phases of Software Change

  • Initiation Requirements and other push for the change
  • Software-Change Design Figure out how the change should be done
  • Software-Change Implementation Implement the change

Software Change: Initiation

  • Starts with a change request
  • Must prioritize
    • Number/percentage of users effected
    • Severity, crash vs. appearance

Software Change: Initiation Examples

  • user reports a software bug
  • user asks for an enhancement
  • programmer proposes improvement
  • manager wants to meet competitor’s functionality

Software Change: Initiation Form

  • Format:
    • Sentence or paragraph
    • Bug report
    • User story
  • Put on product backlog

Software Change: Initiation Issues

  • Noise
    • irrelevant requests (deleted)
  • Unfeasible
    • Project team or technology barriers
  • Ambiguity or unintelligibility
    • More than one way to interpret

Software Change: Prioritization

  1. Fatal application error
  2. Application is severely impaired
    • No workaround can be found
  3. Some functionality is impaired
    • Workaround can be found
  4. Minor problem
    • Does not involve primary functionality

Business Value

  1. An essential functionality without which the application is useless
  2. An important functionality that users rely on
  3. A functionality that users need but can be without
  4. A minor enhancement


  1. A serious threat, i.e., “showstopper”
    • if unresolved, the project is in serious trouble
  2. An important threat that cannot be ignored
  3. A distant threat that still merits attention
  4. A minor inconvenience

Process Needs

  1. Key requirement
    • if not implemented in advance, practically all code will have to be redone
  2. An important requirement
    • if postponed, will lead to large rework
  3. A nontrivial rework will be required if this requirement is postponed
  4. A minor rework will be triggered

Software Change Design

  • concept location
  • impact analysis

Software Change Design

Concept Location

  • Concepts extracted from the change request
  • Extracted concepts are located in the code and used as a starting point of software change

Concept Location Examples

  • Add Discover card for possible credit cards → classes, methods, data structures which involve other credit cards
  • Fix spelling of “password” (from “passwd”) → find out where “passwd” is in system
  • Change API method length() to size() → Rename method refactoring in API

Impact Analysis

  • Determine strategy and impact of change
  • Change has not occurred yet
  • Typically done at a class/file level
  • impact set classes identified in concept location
  • Class dependencies are analyzed, and impacted classes are added to the impact set

Software Change Implementation

  • Prefactoring Getting ready
  • Actualization Performing change
  • Postfactoring Cleaning up


  • Software change often shows that the current design is not optimal for after the change
  • Opportunistic refactoring that localizes (minimizes) impact of software change on software
  • E.g., Extract Class Refactoring (Fowler)
    • Create a new class from fields, methods, and code of an existing class
  • E.g., Extract Superclass Refactoring (Fowler)
    • Create a new abstract class from existing classes


  • Create new code
  • Plug it into existing code
  • Visit neighboring classes and update them
    • change propagation
    • ripple effect
    • Know what this is from impact analysis (if successful)


  • Eliminate any anti-patterns, code smells that may have been introduced
    • E.g., long method after adding functionality, some methods may be doing too much
    • E.g., bloated class after adding functionality, a class may be too large (or doing too much)


  • Guarantee correctness of change
  • Testing
    • unit
    • functional
  • Walkthroughs


  • Many of the previous slides are adapted from the slides for the book “Software Engineering: The Current Practice” by Vaclac Rajlich © 2012 by Václav Rajlich