Credits

• 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

Change Distribution

Schach'03

Functionality

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

Changes

• 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

Risk

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

Prefactoring

• 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

Actualization

• 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)

Postfactoring

• 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)

Verification

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