Software Evolution

Why software evolution is necessary

• Software development continues after the system is delivered and needs to adapt over its lifetime.

• To stay useful, software must change to meet new business needs and user expectations.

• These changes can be driven by new requirements, fixing defects, or updates in the surrounding systems.

• Research shows that 85–90% of software costs come from maintaining and updating systems over time.

“brownfield software development”

• The term "brownfield software development" (Hopkins and Jenkins, 2008) refers to building and managing software that depends on many other systems.

• System evolution usually doesn't happen in isolation.

• Environmental changes can cause system updates, which may lead to further changes in the environment.

Software Lifetime

• Useful software systems can last a long time.

• Military or infrastructure systems, like air traffic control, can last over 30 years.

• Many business systems are more than 10 years old.

Spiral Model of Development and Evolution

1. Specification

2. Implementation

3. Validation

4. Operation

Alternative view of the software evolution life cycle

1. Initial Development

2. Evolution

3. Servicing

4. Phaseout

• Rajlich and Bennett (2000) proposed that in the evolution phase, major changes to software architecture and functionality occur.

• During the servicing phase, only minor, necessary updates are made.

Change identification and evolution processes

• In some organizations, software evolution is informal, with change requests coming from user-developer discussions.

• In other companies, it’s a formal process with structured documentation at each step.

• Change identification and system evolution are ongoing, cyclic processes throughout a system's life.

The Software Evolution process

1. Change Request

2. Impact Analysis

3. Release Planning

   • Fault Repair

   • Platform Adaptation

   • System Enhancement

4. Change Implementation

5. System Release

• The software evolution process (adapted from Arthur, 1988) involves key steps: change analysis, release planning, system implementation, and releasing updates to customers.

• Costs and impacts are assessed to determine how much of the system is affected and the expense of the change.

• If accepted, a new system release is planned.

• During this process, detailed analysis can reveal new issues, leading to modified changes and further customer discussions.

• Urgent changes may be needed to address critical system problems.

Change implementation

Should modify the system specification, design, and implementation to reflect the changes to the system.

1. Proposed Changes

2. Requirements Analysis

3. Requirements Updating

4. Software Development

Three reasons why changes arise

1. A serious system fault needs fixing to restore normal operation.

2. Environmental changes unexpectedly disrupt the system.

3. Unanticipated business changes, like new competitors or laws, impact the system.

• Instead of adjusting the requirements and design, you make an emergency fix to address the immediate issue.

• The risk is that this can lead to inconsistencies between the requirements, design, and code.

Lehman’s Laws

Law 1: Continuing Change

Law 2: Increasing Complexity

Law 3: Large Program Evolution

Law 4: Organizational Stability

Law 5: Conservation of Familiarity

Law 6: Continuing Growth

Law 7: Declining Quality

Law 8: Feedback System

Law 1: Continuing Change

Software must keep changing as the world changes, or it will stop being useful.

Law 2: Increasing Complexity

As software evolves, it becomes more complex. Extra effort is needed to keep it simple and maintainable.

Law 3: Large Program Evolution

Big software systems have their own pace of change. Certain things (like the time between updates or error counts) stay consistent with each update.

Law 4: Organizational Stability

The speed of developing software stays about the same, no matter how much effort or resources you put into it.

Law 5: Conservation of Familiarity

Even though software changes, the rate at which it changes remains mostly stable over time.

Law 6: Continuing Growth

Software must keep adding new features to meet user expectations and satisfaction.

Law 7: Declining Quality

Software quality will decrease unless you keep updating it to match the changes around it.

Law 8: Feedback System

To make big improvements, you need feedback from how the software is used, and this feedback guides future changes.

Software Maintenance

• The process of changing a system after delivery typically applies to custom software with different teams for development and maintenance.

• Changes can range from fixing code errors to addressing design issues or adding new features.

• Changes are made by updating existing components or adding new ones.

Three types of software maintenance

• Fault Repairs

• Environmental Adaptation

• Functionality Addition

Faulty Repairs

• Coding errors are usually cheaper to fix, while design errors cost more since they may require rewriting multiple components.

• Requirements errors are the most expensive, as they often involve extensive system redesign.

Environmental Adaptation

• This type of maintenance is needed when changes occur in the system's environment, like hardware, operating systems, or support software.

• The application must be updated to adapt to these changes.

Functionality Addition

• This maintenance is needed when system requirements change due to organizational or business changes.

• These updates are usually more extensive compared to other types of maintenance.

Maintenance Effort Distribution

• While the exact percentages differ across organizations, fixing system faults is generally not the costliest maintenance task.

• Most maintenance effort goes into adapting the system to new environments and changing requirements.

Legacy Systems

• Legacy systems are old but still useful and often critical to business operations.

• They may use outdated technology, be costly to maintain, and lack proper documentation.

• Despite this, replacing them may not be cost-effective or too risky due to lost specifications.

• To decide whether to replace, transform, or maintain a legacy system, its business value and software quality should be assessed.

Software Reengineering

• This process focuses on restructuring and redocumenting software to enhance understandability and ease of change.

• To make legacy systems easier to maintain, you can reengineer them to improve their structure and clarity.

• Reengineering may involve updating documentation, refactoring the architecture, translating code to modern languages, and modifying the system's data structure.

• The software's functionality remains unchanged, and major architectural changes should generally be avoided.

The Software Reengineering Process

1. Source Code Translation

2. Reverse Engineering || Program Structure Improvement

3. Program Modularization

4. Data Reengineering

Source Code Translation

A translation tool converts the program from an old programming language to a modern version or a different language.

Reverse Engineering

The program is analyzed to extract information, helping to document its organization and functionality. This process is usually automated.

Program Structure Improvement

The program's control structure is analyzed and modified for better readability. This can be partially automated, but some manual work is typically needed.

Program Modularization

Related parts of the program are grouped together, and redundancies are removed. This may involve architectural refactoring, such as consolidating multiple data stores into one. This step is manual.

Data Reengineering

The program's data is updated to reflect changes, which may involve redefining database schemas and converting existing databases. Data cleanup is also necessary, including correcting mistakes and removing duplicates. Tools are available to assist with this process.

Benefits of Reengineering

• Reduced Risk

• Reduced Cost

Reduced Risk

Redeveloping business-critical software carries high risks, such as errors in specifications or development issues.

Reduced Cost

Reengineering can be significantly cheaper than developing new software. For example, Ulrich (1990) noted that a system's reimplementation was estimated at $50 million, while it was successfully reengineered for just $12 million.

Refactoring

• Involves making small changes to a program that maintain its functionality and can be seen as preventative maintenance to reduce future issues.

• It focuses on improving the program's structure, reducing complexity, and enhancing understandability (Opdyke and Johnson, 1990).

• The goal of refactoring is to improve the program without adding new features, concentrating solely on its enhancement.

Comparison between Reengineering and Refactoring

Reengineering

• Occurs after a system has been maintained for a while and maintenance costs start to rise.

• It utilizes automated tools to process and reengineer a legacy system, resulting in a new system that is easier to maintain.

Refactoring

• A continuous improvement process during development and evolution.

• It aims to prevent the degradation of structure and code, which can increase maintenance costs and difficulties.

Examples of “bad smells” that can be improved through refactoring

• Duplicate Code

• Long Methods

• Switch (Case) Statements

• Data Clumping

• Speculative Generality

Duplicate Code

• Similar code appears in different places in a program.

• This can be eliminated by creating a single method or function that can be called as needed.

Long Methods

Methods that are too long should be broken down into shorter, more manageable methods

Switch (Case) Statements

• These often involve duplication based on the value type and may be scattered throughout the program.

• In object-oriented languages, polymorphism can often replace switch statements for the same functionality.

Data Clumping

• Data clumps occur when the same group of data items (like fields in classes or parameters in methods) appear in multiple places.

• These can often be replaced with a single object that encapsulates all the related data.

Speculative Generality

• This happens when developers add unnecessary generality in case it is needed in the future.

• Often, this unnecessary complexity can simply be removed.