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
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% |
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
- 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
- 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
- Fatal application error
- Application is severely impaired
- Some functionality is impaired
- Minor problem
- Does not involve primary functionality
Business Value
- An essential functionality without which the application is useless
- An essential functionality that users rely on
- A functionality that users need but can be without
- A minor enhancement
Risk
- A severe threat, i.e., "showstopper"
- if unresolved, the project is in serious trouble
- A critical threat that is not ignorable
- A distant threat that still merits attention
- A minor inconvenience
Process Needs
- Key requirement
- If not implemented in advance, practically all code has to be redone
- Important requirement
- if postponed, it leads to a substantial amount of rework
- Nontrivial rework required if we postpone this requirement
- 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