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 Vaclav Rajlich © 2012 by Václav Rajlich

Software Change

  • software change (SC) is the process of adding new functionality to existing code
  • Foundation of
  • 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 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 - affects only small, immediate part of code, i.e., individual method, class, or small namespace/package
  • significant impact - affects 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 of the 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 to implement the change
  • Software-Change Implementation Implement the change

Software Change: Initiation

  • Starts with a change request
  • Must prioritize
  • Number/percentage of users affected
  • 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 the 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 is found
  3. Some functionality is impaired
    • Workaround is found
  4. Minor problem
    • Does not involve primary functionality

Business Value

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


  1. A severe threat, i.e., "showstopper"
    • if unresolved, the project is in serious trouble
  2. A critical threat that is not ignorable
  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 has to be redone
  2. Important requirement
    • if postponed, it leads to a substantial amount of rework
  3. Nontrivial rework required if we postpone this requirement
  4. Minor rework is 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 for software change

Concept Location Examples

  • Add Discover card for possible credit cards → classes, methods, and data structures that involve other credit cards
  • Fix the spelling of "password" (from "passwd") → find out where "passwd" is in the 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
  • Opportunistic refactoring that localizes (minimizes) the impact of software change on the software
  • E.g., Extract Class Refactoring (Fowler)
  • Create a new class from the 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
  • Set is known from impact analysis (if successful)


  • Eliminate any anti-patterns, code smells caused by the actualization
  • 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