Software Evolution, Maintenance, and Reengineering: Managing Legacy Systems

Posted on Sep 3, 2024 in Other subjects

Lehman’s Laws of Software Evolution

Inevitable Evolution: The first law states that maintaining a software system is an inevitable process. As the system’s environment changes, new requirements emerge, necessitating system modifications. These modifications, when reintroduced into the environment, trigger further environmental changes, restarting the cycle of evolution.

Degradation of Structure: The second law posits that system changes lead to structural degradation. The only way to mitigate this is through preventive maintenance, which involves investing time and resources in improving the software’s structure without adding new features. This, however, incurs additional costs beyond those required for implementing system changes.

Dynamics: The third law suggests that large systems develop their own dynamics early in the development process. These dynamics dictate the system’s tendencies and limitations regarding potential changes. Lehman and Belady argue that this law stems from structural factors influencing and restricting system changes, as well as organizational factors impacting system evolution.

Types of Software Maintenance

Corrective Maintenance: This involves fixing software defects. Correcting encoding errors is typically inexpensive, while addressing design errors can be more costly, potentially requiring system redesign.

Adaptive Maintenance: This type of maintenance is necessary when aspects of the system environment change, such as hardware, operating system, platform, or other supporting software. The application system must be modified to accommodate these environmental changes.

Evolutionary Maintenance: This arises when system requirements change due to organizational or business changes. Evolutionary maintenance demands a larger scale of software modifications compared to other maintenance types.

Forecasting Maintenance Change Requests

Accurately forecasting maintenance change requests is crucial for managing costs and avoiding surprises. Key factors to consider include:

Ease of maintenance: The decision to accept a system change depends partly on the ease of maintaining the affected components.
Structural degradation: System changes tend to degrade its structure, reducing maintainability.
Maintenance costs: These depend on the number of changes, and the cost of implementing changes depends on the maintainability of system components.

Predicting change requests requires understanding the relationship between the system and its external environment. Evaluate the following:

Number and complexity of system interfaces: More and complex interfaces increase the likelihood of change requests.
Number of volatile system requirements: Requirements reflecting organizational policies and procedures are more prone to change than those based on stable domain characteristics.
Business processes using the system: Evolving business processes generate change requests. More processes using the system lead to more change requests.

Metrics for Evaluating Maintainability

Several process metrics can help evaluate maintainability:

Number of corrective maintenance requests: An increase in crash reports may indicate more errors being introduced than fixed, suggesting declining maintainability.
Average time for impact analysis: This reflects the number of components affected by a change request. Increasing time suggests declining maintainability.
Average time to implement a change request: While correlated with impact analysis time, this metric measures the time to change the system and documentation after assessing affected components. Increasing time indicates declining maintainability.
Number of pending change requests: An increasing backlog suggests declining maintainability.

Urgent Change Requests

Urgent change requests often stem from system problems requiring immediate attention. These can arise due to:

Serious system defects: Requiring immediate repair for normal operation.
Unexpected environmental changes: Disrupting normal operation due to unforeseen changes in the operating environment.
Unforeseen business changes: Necessitating emergency changes due to new competitors or legislation.

Software Reengineering

Reengineering offers advantages over radical system evolution:

Reduced risk: Redeveloping business-critical software carries high risk. Errors in specifications or development problems can occur. Delays in introducing new software can lead to business loss and extra costs.
Reduced cost: Reengineering is significantly cheaper than developing new software.

Reengineering Activities

Source code conversion: Converting code to a more modern version of the same language or a different language.
Reverse engineering: Analyzing the program to extract information, aiding in documenting its organization and functionality.
Program structure improvement: Modifying the control structure for better readability and comprehension.
Program modularization: Grouping related program parts, removing redundancies, and potentially transforming the architecture (e.g., from centralized to distributed).
Data reengineering: Changing processed data to reflect program changes.

Factors Affecting Reengineering Costs

Software quality: Lower quality software and documentation increase reengineering costs.
Available tools: Using CASE tools to automate changes is crucial for cost-effectiveness.
Data conversion: Converting large data volumes significantly increases costs.
Skilled personnel: Involving system maintainers in reengineering can increase costs as reengineering engineers need time to understand the system.

The main disadvantage of reengineering is the practical limitation on the extent of improvement possible.

Managing Legacy Systems

Organizations with limited budgets for legacy system maintenance and upgrades have four strategic options:

Discard the system: When the system no longer effectively contributes to business processes.
Maintain the status quo: When the system remains necessary but stable, with few user change requests.
Re-engineer the system: When regular changes have degraded system quality and further changes are needed.
Replace the system: When factors like new hardware necessitate replacement or when commercially available systems offer a cost-effective solution.

Categorizing Legacy Systems

Low quality, low market value: Costly to maintain with little business value. Discard these systems.
Low quality, high market value: Contribute significantly but are expensive to maintain. Re-engineer to improve quality or replace if a suitable commercial system exists.
High quality, low market value: Inexpensive to maintain but contribute little. Continue maintenance if no costly changes are needed; otherwise, discard.
High quality, high market value: Keep in operation with regular maintenance.

Assessing Market Value

Identify system stakeholders (end-users, managers) and discuss these questions:

System usage: Infrequent use or a small user base suggests low market value.
Business process support: Inability to adapt to changing business processes indicates low market value.
System reliability: Unreliable systems negatively impacting customers or requiring workarounds have low market value.
System outputs: Outputs critical for business operations indicate high market value; easily replaceable or rarely used outputs suggest low market value.

Assessing Technical Quality

Evaluate factors related to reliability, maintainability, and documentation. Collect quantitative data such as:

Number of change requests: Higher numbers suggest lower quality.
Number of user interfaces: More interfaces increase the likelihood of inconsistencies and redundancies.
Data volume: Larger volumes indicate higher complexity.

While useful, collecting this data can be expensive. Consider the system’s age and size when judging quality based on these measurements.