example use case templatesample test plan templateProject plan template
ICS 121: Maintenance: Modularity and Refactoring
- What is Maintenance?
- What is Modularity?
- What is Refactoring?
What is Maintenance?
- Maintenance is all the work that needs to be done on a software
product after it is initially put into use.
- In older views of software development, maintenance was seen as
one additional step after implementation, test, and deployment.
Unfortunately, this one step gradually took a bigger and bigger
percentage of effort.
- Now, maintenance is seen as a new iteration of the development
life-cycle where work starts with revising the requirements of the
previous release rather than starting from a blank page.
- If a product has 20 releases in 6 years, 19 of those release
- Common types of changes in post-1.0.0 releases:
- Defect repair
- Keeping up with environmental change (e.g., Windows XP comes out)
- Enhancements to existing features
- Whole new features
- Design and implementation improvements
- Performance enhancements
- Maintenance effort is determined by:
- Design understandability and modularity
- Coding style understandability
- Implementation quality: number of existing defects
- Understandability of technical documentation
- Skills and experience of development team
- Scope of requested changes
- Tools available for maintenance
- Note: The term "maintenance release" is more narrowly defined:
it refers to a 3-digit release, e.g., 2.0.1. These releases
typically have only defect repair, not new functionality.
What is Modularity?
- Modularity is how well the product is divided into independent modules
- Low coupling
- High cohesion
- Things to look for:
- Cycles in the package dependency graph
- Classes with too many import statements
- Public attributes
- One class treats another class like a simple data record
What is Refactoring?
- Refactoring is moving pieces of source code from one place in
the system to another, changing a method signature, or changing the
class structure, or renaming elements.
- Refactoring is typically tedious and error prone because a
developer must search through all the other code and make
- Refactoring can be made easier with tools
- A good search and replace utility always helps, but cannot catch everything
- Round-trip UML tools read code, allow design changes, then generate revised code
- Newer IDEs and editors have sophisticated commands for specific refactoring operations
- Guidelines for refactoring:
- Have a specific goal in mind, don't just polish code
endlessly. Don't do it everyday when you feel like it, do it
according to a project plan.
- Do not refactor and add new logic at the same time: finish one and test, then do the other
- Run automated regression tests before and after a refactoring
session. You should get the same results.
- Manage the scope of the change. Refactor in short, deliberate
steps and test after each step.
- Keep in mind that other code that you cannot edit might depend
on your API. In java, mark old methods with deprecated javadoc tag.
- For more, see Eclipse
documentation on refactoring