Software Maintenance and Legacy Systems Quiz

Software Evolution and Maintenance

• Software change is inevitable. New requirements, changing business environments, error repairs, new equipment additions, and performance/reliability improvements are constant.
• Implementing and managing changes to existing software systems is a key problem for all organizations.
• Organizations invest heavily in software systems, viewing them as critical business assets. Maintaining their value necessitates updating and changing them. Most software budgets go toward modifying or evolving existing systems, not developing new ones.
• A spiral model is used for development and evolution. The model shows repeating cycles of specification, implementation, operation, and validation stages. The spiral cycles can lead to multiple software releases (1, 2, 3 etc).

Evolution and Servicing

• Evolution is the stage in a software system's life cycle where it is in operational use and changing with new requirements.
• Servicing describes the stage where a software is still useful but only requires changes that help keep it operational (e.g. bug fixes, environment changes). No new functions are added. Lastly, phase-out is when no more changes are made.
• The image shows software development, evolution, servicing and retirement over time.

Evolution Processes

• Software evolution processes vary based on the software's type, the development processes used, and the skills of involved personnel.
• Change proposals are the drivers for system development. These proposals need to be linked to the affected components to estimate costs and impacts.
• Change identification and evolution continues throughout the system's life cycle.

Change Identification and Evolution Processes

• Change identification (starting point of the cycle).
• Software evolution processes.
• Change proposals (resulting from process).

The Software Evolution Process

• The process starts with change requests.
• Impact analysis is performed next.
• Then release planning is carried out.
• Change implementation comes after.
• System release follows.
• Platform adaptation is a necessary step in the process.
• Fault repair may also be included in the process.
• System enhancement occurs after successful release.

Change Implementation

• Proposed changes initiate the process.
• Requirements analysis follows, leading to requirements updating.
• Software development is the final stage of the process

Urgent Change Requests

• Urgent changes may bypass the usual software engineering process.
• Urgent changes usually occur due to serious system faults or unexpected changes to the environment (like an OS upgrade).
• Business pressures, such as a competing product's launch, also may prompt urgent changes.

The Emergency Repair Process

• Change requests trigger the process.
• Source code analysis follows.
• Source code modification is applied.
• The modified system is delivered.

Agile Methods and Evolution

• Agile methods, based on incremental development, make the transition from development to evolution seamless.
• Evolution is a continuation of the development process, with frequent releases.
• Automated regression testing aids in maintaining quality when changes are made to a system.

Handover Problems

• Handover issues arise when the development team uses Agile methods but the evolution team prefers a plan-based approach. A key problem is a lack of documentation in Agile processes, which the evolution team may expect to be present.
• Conversely, handover problems can also occur when the development team uses a plan-based methodology while the evolution team prefers Agile methods. In this case, the codebase might not have been adequately refactored or simplified.

Legacy Systems

• Legacy systems rely on older technologies and languages.
• Such systems may depend on obsolete hardware like mainframe computers.
• Legacy systems encompass the hardware, software, libraries, and supporting software, all interwoven with business processes.
• The illustration displays the interconnected components of a legacy system: support software, runs-on system hardware, application software, application data, business processes (policies).

Legacy System Components

Legacy systems comprise: hardware, support software, application software, application data, business processes, and business policies and rules. The hardware may be obsolete. Support software can be outdated or unsupported. The application system may contain multiple application programs that provide business services. Application data is processed by the application system and may be inconsistent, duplicated, or housed in disparate databases.

Legacy System Layers

• The components of a legacy system are arranged hierarchically, with hardware at the base and socio-technical systems at the top. The layers include hardware, platform/infrastructure software, application software, and business processes.

Legacy System Replacement

• Replacing legacy systems is often risky and expensive.
• Reasons for risk include incomplete system specifications, complex integrations between systems and business processes, undocumented business rules, and potential delays or budget overruns in new software development.

Legacy System Change

• Legacy system modifications are expensive because consistent programming styles are often missing. Also, outdated programming languages used may have limited skilled personnel. System documentation may be inadequate, and programs may have significant structure degradation. Data issues (errors, duplication, and inconsistency) are frequently present.

Legacy System Management

• Organizations using legacy systems must choose a suitable strategy for evolution:
• Scrap the system completely to avoid maintaining it.
• Continue maintaining the system using existing procedures.
• Transform the system via re-engineering to increase maintainability.
• Replace the system altogether with a new one.
• The chosen strategy should depend on the legacy system's quality and business value.

An Example of a Legacy System Assessment

• An illustration depicts a scoring system where legacy systems are categorized based on business value and system quality.

Legacy System Categories

• Low quality, low business value systems should be scrapped.
• Low-quality, high-business value systems should be re-engineered or replaced if suitable alternatives exist.
• High-quality, low-business value systems can be replaced with commercial-off-the-shelf (COTS) software, scrapped, or maintained.
• High-quality, high-business value systems should continue operation using standard maintenance procedures.

Business Value Assessment

• System end-users, business customers, line managers, IT managers, and senior managers should be considered during assessment.
• Different stakeholder viewpoints should be gathered and analyzed.

Issues in Business Value Assessment

• System use frequency. If use is limited, business value is likely low.
• Inefficient business processes. If the system forces inefficient business processes, business value is likely low.
• System dependability. If the system is unreliable or causes problems for customers, business value is likely low.
• System outputs. Systems valuable to a business are ones where the business depends on the system's outputs.

System Quality Assessment

• How well does the business process support current business goals?
• How effective is the environment of the system and how costly is it to maintain?
• What is the quality of the application software system?

Business Process Assessment

• Use viewpoints from stakeholders to understand system use.
• Define process models and confirm usage consistency among different organizational parts.
• Assess how the process has been adapted.
• Evaluate interactions with other business processes.
• Decide if the process is effectively supported by the application software.

Factors used in Environment Assessment

• Supplier stability questions determine if the supplier is financially stable, actively maintains the system, and continues to exist.
• Failure rate questions determine the system's hardware reliability.
• Age questions assess the system's obsoleteness and its implications for the business.
• Factors relating to performance, support requirements, maintenance costs, and interoperability are also considered.

Factors used in Application Assessment

• Understandability questions assess how complex the system code is.
• Documentation questions assess if comprehensive and current documentation is available.
• Data questions evaluate data models, data duplication, and data consistency.
• The performance, programming language(s), configuration management, and test data needed, along with the skills of personnel, are also assessed.

System Measurement

• Collecting quantitative data helps assess application system quality.
• The number of system change requests is a helpful metric; high numbers indicate potential system degradation.
• Determining the number of system's user interfaces is an important metric; high numbers imply possible inconsistencies, redundancies, or issues.
• Assessing system data quantity and quality helps identify data-related issues. Cleaning old data can be exceptionally costly and time-consuming.

Software Maintenance

• Modifying a program after initial deployment, often associated with custom software.
• Generic software often evolves through new versions.
• Maintenance typically does not dramatically alter the system architecture.
• Changes are usually achieved by altering existing components and adding new ones.

Types of Maintenance

• Fault repairs (fixing bugs)
• Environmental adaptation (altering for different environments)
• Functionality addition and modification (adding/changing features).

Why Modifications are Required

• Market conditions, such as updated policies and regulations (taxation).
• Client requirements like new software features.
• Changes related to the host system like hardware or OS changes.
• Organizational changes, like company growth or restructuring.

Types of Maintenance (continued)

• Corrective Maintenance - fixing errors.
• Adaptive Maintenance - adapting to changes in technology/business environment.
• Perfective Maintenance - improving performance or adding new features.
• Preventive Maintenance - addressing potential future problems in the software.

Maintenance Effort Distribution

• Maintenance effort breakdown ( pie chart) roughly shows: 58% of effort is for functionality additions/modifications; 24% for fault repairs; 19% for environmental adaptations.

Maintenance Costs

• Typically, software maintenance costs far exceed development costs, sometimes drastically.
• Both technical and non-technical factors contribute to maintenance costs.
• Maintenance costs increase as maintenance is performed, making software further maintenance more complex.
• Aging systems often have substantially higher maintenance expenses .

Maintenance Costs (continued)

• Adding new features during maintenance is usually more expensive than during development, partly because a different, possibly inexperienced, team has to understand the older system.
• Separate maintenance and development teams can mean little incentive for developers to write clearly structured code. Also, maintenance staff can have less deep understanding of the domain, and the initial structure of the software may have degraded.

Software Maintenance Cost Factors

• Non-technical factors, such as industry domain or staff stability, also significantly impact maintenance costs.
• Technical factors concern the software architecture and quality: module independence / programming language / programming style / program validation, and testing effectiveness, and documentation and configuration management techniques.

Maintenance Efforts

• Maintenance effort can be broken down into productive activities. This includes analysis, design, modification, and coding.

Maintenance Prediction

• Predicting maintenance costs requires understanding which system parts are likely to cause failures during their operational lifetime and the impact on maintainability.
• Accepting a change is linked to the system's maintainability, and implementing changes can lead to degradation. Maintenance costs are impacted by the frequency and complexity of changes and their impact on system maintainability.

Change Prediction

• Predicting the number of changes needs an understanding of relationships between a system and its environment.
• Coupled systems are likely to need changes whenever the environment changes.
• Key factors include the complexity and number of system interfaces, the nature of system requirements, and the business processes utilizing the system.

Complexity Metrics

• Maintainability can be predicted by assessing complexity within components.
• Maintaining effort tends to be focused on a small number of components.
• Control structures, data structures, and object/method/module sizes are components of complexity.

Process Metrics

• Process metrics (number of requests, average impact analysis / implementation times, outstanding requests) assess maintainability.
• Increases in these metrics often correlate with a decrease in maintainability.

Software Reengineering

• Reengineering modifies or rewrites parts/all of a legacy system without changing its functionality.
• This is best suited for subsystems that require frequent maintenance within a larger system.
• Software reengineering can involve structural and documented revisions of a system.

Advantages of Reengineering

• Risk reduction. Risk associated with new software development is smaller with reengineering.
• Reduced cost. Reengineering is often significantly more cost-effective than developing entirely new software.

The Reengineering Process

• The reengineering process involves these steps: original program, reverse engineering, source code translation, program improvement, program modularization, restructuring, and re-engineered data. It includes data reengineering to handle raw data in a new format.

Reengineering Process Activities

• Source code translation to a new language.
• Reverse engineering to understand the original program.
• Program structure improvement to increase maintainability.
• Program modularization for better code organization.
• Data reengineering to improve data structures.

Reengineering Approaches

• Automated program restructuring.
• Manual changes, often based on automation with human intervention.
• Restructuring including architectural changes. Automated changes are more cost-effective.

Reengineering Cost Factors

• Reengineering costs depend on the quality of the software being re-engineered, the tools supporting the process, the data conversion needs, and the expertise of personnel performing reengineering.

Refactoring

• Refactoring improves program structure for better maintainability and less degradation over time.
• Refactoring involves modifications that improve program structure, decrease complexity, and enhance understanding.
• Functionality is not added during refactoring; only internal improvements are made.

Refactoring and Reengineering

• Re-engineering often happens after significant maintenance, driven by increasing costs. Tools accelerate the re-engineering process.
• Refactoring is an ongoing process. It enhances the software's structure and maintainability during development, avoiding extensive degradation that increases maintenance costs.

'Bad Smells' in Program Code

• Duplicate code: identical or highly similar program segments should be isolated into reusable units.
• Long methods: long methods should be broken down into shorter, more focused routines.
• Switch statements: switch statements can be improved by using polymorphism in object-oriented languages to reduce repetition.

'Bad Smells' in Program Code (Continued)

• Data clumping: repeating data groupings can be refactored into reusable objects to better handle data.
• Speculative generality: unnecessary generality should be removed if it is not needed at that time.

Key Points

• Software development and evolution are integrated processes.
• Maintenance costs commonly surpass development costs for custom systems.
• Evolution is driven by requests for change. This includes impact analysis, planning, and implementation.
• Legacy systems (still useful, but outdated) are often better maintained than replaced if the value continues to be important.
• Alternative methods (e.g. refactoring or re-engineering) are often suitable for a legacy system.
• There are different types of maintenance (bug-fixing, adapting to new environments, new feature implementation, etc.) that support a legacy system needing evolution.

This quiz explores key concepts in software maintenance, focusing on the factors affecting costs, maintainability metrics, and the characteristics of legacy systems. Test your knowledge on the challenges of software reengineering and the dynamics of tightly coupled systems.