CHAPTER 9: SOFTWARE EVOLUTION
EVOLUTION PROCESS
SOFTWARE MAINTENANCE
PROGRAM EVOLUTION DYNAMICS
LEGACY SYSTEM MANAGEMENT
Why software change is inevitable?
Change of business environments
Repair errors
Emergence of new requirements
New computers and equipments
Improve performance or reliability
Spiral Model of Development and Evolution
Evolution and Servicing
[Servicing] Still functional but only required changes are made, no new functionality is added
[Phase-Out] Still in used but no further changes will be made to it
[Evolution] The stage where it is in operational use and is evolving as new requirements is proposed and implemented to the system
Process depends on?
Development process used
Skills and experience of the people involved
Type of software being maintained
Change Identification and Evolution Process
Software Evolution Process
Change Implementation
click to edit
The first stage may involve program understanding especially if the original system developers are not responsible for the change implementation
Need to understand how the program is structured, how it delivers functionality and how the proposed system might affect the program
Iteration of the development process where the system revisions are designed, implemented and tested
Emergency Repair
If changes to the system's environment have unexpected effects
If there are business changes that require a very rapid response
If a serious system fault has to be repaired to allow normal operation to continue
Handover Problems
When a plan based approach has been used for development but the evolution team prefer to use agile methods
When the development team used an agile approach but the evolution team is unfamiliar with agile method and prefer a plan based approach
The evolution team may expect detailed documentation to support evolution and this is not produced in agile processes
The evolution team may have to start from scratch developing automated tests and the code in the system may not have been refactored and simplified as is expected in agile development
Strategy for Evolving Legacy Systems
Continue maintaining the system
Transform the system by re-engineering to improve its maintainability
Scrap the system completely and modify business processes so that it is no longer required
Replace the system with a new system
Categories
Low quality, high business value
High quality, low business values
Low quality, low business value
High quality, high business values
Scrap the system
Re-engineered or replaced
Replace with COTS, scrap completely or maintain
Continue in operation
Issues in business value assessments
Low business values if it forces the use of inefficient business processes
Low business values if the system is not dependable and the problems directly affect business customers
Low business value when it is used by only a small number of people
High business values if the business depends on the system outputs
Factors in Environment Assessments
Age
Performance
Failure Rate
Support requirements
Supplier Stability
Maintenance costs
Interoperability
Understandability
Documentation
Data
Performance
Programming Language
Configuration Management
Test Data
Personnel skills
What is program evolution dynamics?
Types of maintenance
Maintenance to adapt software to a different operating environment
Maintenance to add to or modify the system's functionality
Maintenance to repair software results
The study of the processes of system damage
Change is inevitable?
Environment is changing so the system won't meet its requirement
System requirement changes
System MUST be changed if they are to remain useful
Lehman's law
Applicable to large tailored systems developed by large organisation
It is not clear how they should be modified for
Shrink-wrapped
System that have significant numbers of COTS
Small organisation
Medium sized systems
Modifying a program after it has been put into use
Maintenance effort distribution
Maintenance cost
Factor
Team stability
Contractual responsibility
Staff skills
Program age and structure
Maintenance prediction
Reengineering
Advantages
Reduced risk and cost
Process
Cost factors
The tool support for reengineering
The extent of data conversion which is required
The quality of software to be reengineered
The availability of expert staff for reenginering
"Bad smells" in program code
Duplicate code
Long method
Speculative generality
Switch (case) statements
Data clumping