Thomas M. Pigoski. 1996. Practical Software Maintenance: Best Practices for Managing Your Software Investment (1st ed.). Wiley Publishing.
Software Evolution
Plan
Basic Definitions
Evolution and Maintenance
Types of Software Maintenance
There are 4 types of maintenance, wrt the goal of the maintenance activity: (i) Adaptive, (ii) Corrective, (iii) Perfective, and (iv) Preventive.
«Adaptive maintenance is the maintenance activity performed to make a computer program usable in a changed environment.»
Occurs as a result of external influences or strategic changes.
For instance:
The government creates new taxes or changes the VAT rate.
A bank buys another one and their system must be integrated into their own system.
«Corrective maintenance is the maintenance activity performed to correct faults in hardware or software.»
Occurs when customers detect a deviation of the software from its expected behavior, which was not detected during development.
«Perfective maintenance is the maintenance activity performed to improve the performance, maintainability, or other properties of software.»
Occurs after the deployment, when customers ask for minor improvements in the software.
For instance:
Better validation, simpler data input, better performance.
«Preventive maintenance is the maintenance activity performed for the purpose of preventing problems before they occur.»
For instance:
Improve maintainability: modularity, testability, understandability, portability, etc.
Maintenance classification
A legacy software system is any system that significantly resists modifications and changes while remaining of significant value for its owner. The system might have been developed using an outdated programming language or an obsolete development method. Most likely, it has changed hands several times and shows many signs of degradation.
Figure 1. Millions Lines of Code
Reengineering is the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form. Reengineering generally includes some form of reverse engineering (to achieve a more abstract description) followed by some form of forward engineering or restructuring. This may include modifications to fulfill new requirements not met by the original system.
«Forward engineering is the traditional process of moving from high-level abstractions and logical, implementation-independent designs to the physical implementation of a system.»
Reverse engineering is the process of analyzing a subject system to identify its components and their interrelationships and to create representations of the system in another form or at a higher level of abstraction.
Reverse engineering generally involves extracting design artifacts and building or synthesizing abstractions that are less implementation-dependent.
Reverse engineering with Modisco
Plan
Software Aging
«Programs, like people, get old. We cannot prevent aging, but we can understand its causes, take steps to limit its effects, temporarily reverse some of the damage it has caused, and prepare for the day when the software is no longer viable.»
Why software ages?
Software Change is inevitable!
New requirements emerge when the software is used
The business environment changes
Errors must be repaired
New computers and equipment are added to the system
The performance or reliability of the system may have to be improved
A key problem for all organizations is implementing and managing change to their existing software systems.
Importance of Evolution
Cost of Maintenance in a Software Life
Changes Induce Technical Debt
As a change is started on a software system, often there is a need to make other coordinated changes at the same time in other parts of the software.
These other required changes, if not completed immediately, incur a kind of debt that must be paid at some point in the future.
This technical debt is “the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”.
Changes Induce Technical Debt (Cont.)
Just like financial debt, if technical debt is not repaid, the uncompleted changes accumulate interest on top of interest, because of increased entropy.
The longer you wait to make the changes, the harder it becomes.
Change is Hard to Anticipate
Many changes cannot be anticipated at design time:
The fundamental problem, supported by 40 years of hard experience, is that many changes actually required are those that the original designers cannot even conceive of.
2000
— Bennett and Rajlich
— Bennett and Rajlich
The Uncertainty Principle in Software Engineering
Software Evolution
Figure 2. Python Evolution Storyline
Ogawa, Michael, and Kwan-Liu Ma. "Software Evolution Storylines." (2010).
Evolution may arise
Static vs. Dynamic Software Evolution
Static evolution
changes are applied manually by a human programmer
part of the software gets adapted or replaced by a programmer and the evolved software is redeployed
Dynamic evolution
changes are applied automatically at runtime
to better suit the current needs of the software system
by automatically generating, adapting, transforming or selecting parts of the software
e.g., self-adaptive systems, context-oriented programming, etc.
Plan
Laws of Software Evolution
Laws of Software Evolution (Cont.)
These laws are the results of studies of the evolution of large-scale proprietary or closed source system (CSS).
The laws concern what Lehman called E-type systems: «Monolithic systems produced by a team within an organization that solve a real world problem and have human users.»
Laws of Software Evolution (Cont.)
In 2009, Xie et al. applied Lehman’s laws to 7 different open source projects.
Guowu Xie, Jianbo Chen and Iulian Neamtiu, "Towards a better understanding of software evolution: An empirical study on open source software," 2009 IEEE International Conference on Software Maintenance, Edmonton, AB, 2009, pp. 51-60.
Continuing change (1st law)
A software system that is used in a real-world environment must necessarily change, or else become progressively less useful in that environment.
Figure 3. Cumulative changes and ratio of changes to Samba.
Increasing complexity (2nd)
As an evolving software system changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure.
Figure 4. Slope and correlation coefficients showing how program complexity changes over time.
Self-regulation (3rd)
Software evolution is a self-regulating process. Software properties such as size, time between releases, and the number of reported errors is approximately invariant for each system release.
Figure 5. Incremental module growth for OpenSSH.
Conservation of organizational stability (4th)
Over a software system’s lifetime, its rate of development is approximately constant and independent of the resources devoted to its development.
Figure 6. Change and growth rates for Samba
Conservation of familiarity (5th)
Continuing growth (6th)
The amount of functionality in a software system will increase over time, in order to satisfy its customers.
Figure 7. Evolution of application size
Declining quality (7th)
Feedback system (8th)
Applicability of Lehman’s laws
However
Plan
Maintenance
Software is knowledge
Maintenance needs knowledge
Types of knowledge
Saving knowledge
Software Metrics
Some Metrics for Maintenance
Guava’s view from Code City
System size (eg: LOC)
Effort (eg: man/hour)
Schedule (eg: start/end dates)
Quality (eg: number of errors)
Be Careful with Metrics
Need to be analyzed in context
Not an end but a mean (not a goal but a tool)
Plan
Figure 8. Software Maintenance Process
ISO/IEC 14764:2006, Software Engineering — Software Life Cycle Processes — Maintenance
Activities
The maintenance process comprises the following high- level activities:
Process Implementation.
Problem and Modification Analysis.
Modification Implementation.
Maintenance Review and Acceptance.
Migration.
Retirement.
Process Implementation
Software and organization need to be prepared
Prepare maintenance when development starts
Prepare software:
Where is the source code?
Is there documentation? How to make change (VCS)?
Prepare organization:
What is the maintenance process?
Who is responsible for what?
Problem and Modification Analysis
Analyze and confirm request
Reproduce (with a test - TDD)
Classify (adaptive, corrective, emergency corrective, etc.)
Check its validity (Real bug? Needed new feature?)
Propose a solution
Estimate costs, plan (schedule)
Consider several possible solutions and compare them objectively
Problem and Modification Analysis (Cont.)
Document the request and the solution proposal
Software is knowledge!
Documentation can take several forms (models, comments, wiki, formal document, commit message, etc.)
Obtain authorization to apply solution
You might be the authorizing authority (simplified process)
Modification Implementation
Implement solution
Bug fix for corrective maintenance
Development process for evolution
Test modification and system
Regression testing (did not break some other part of the system)
Maintenance Review and Acceptance
Review and approval
Might require formal approval (ex: Quality Assurance authority)
Migration
Large modification
Potentially affects all users
Might change more than the software
Hardware, OS, DB, …
Migration
Plan
When, who, why
Parallel operations
Data conversion
Backup old version, old data
Notify
Identify affected people
Notify in advance
Notify when finished
Retirement
End of life of software system
Similar to migration
Plan, Notify, Parallel operation, Archive
Plan
Maintenance Misconceptions
Maintenance is complex
Maintenance is boring
Sometimes, complex things are more interesting than simple ones.