The Software Evolution Processes

Chapter 9.4 · Updated October 2025

Written By:

Angel Bert M. Gonzales

Software evolution is a complex activity that involves many different processes. These vary depending on the type of software being maintained, the development practices used in an organization, and the skills of the people involved. In some organizations, evolution may be an informal process where change requests come from conversations between system users and developers. In others, it is highly formalized with structured documentation at every stage.

System change proposals are the driver for system evolution in all organizations. They may come from existing requirements that have not yet been implemented, bug reports from users, new requests for functionality, or improvement ideas from the development team. The processes of change identification and system evolution are cyclic and continue throughout the system’s lifetime (Figure 9.3).

Change proposals should be linked to the components of the system that must be modified. This makes it possible to assess both the cost and the impact of a change. This is part of the broader process of change management, which ensures the correct versions of components are included in each release.

Figure 9.4 — The software evolution process

The main activities in the evolution process are as follows:

  • Change analysis
  • Release planning
  • Change implementation
  • Emergency repairs
  • Agile methods and evolution

Change Analysis

Change analysis involves understanding the proposed changes and their implications for the system. This includes assessing the costs, benefits, and risks of making the changes. It may also involve prototyping to explore possible solutions.

During change analysis, developers must understand how the proposed changes will affect the existing system. This may involve studying documentation, examining the code, and consulting with users and other stakeholders.

Release Planning

Release planning involves deciding which changes will be included in the next system release. This requires balancing the need for new functionality with the costs and risks of making changes. It may also involve scheduling releases to align with business needs.

During release planning, priorities must be set for the proposed changes. This may involve negotiating with stakeholders to agree on which changes are most important. The plan should also consider the resources available for implementing the changes.

Change Implementation

Change implementation can be thought of as an iteration of the development process — designing, implementing, and testing revisions to the system. A critical difference, however, is that the first step often involves program understanding. Developers must study the structure and functionality of the system to avoid introducing new problems.

Figure 9.5 — Change implementation

Ideally, changes should also update the system’s specification and design to remain consistent. Sometimes, prototyping may be used to explore and validate proposed changes.

Emergency Repairs

Not all changes follow the formal process. Urgent situations may require emergency fixes. These can arise when:

  • A serious system fault prevents normal operation.
  • Unexpected effects in the operating environment disrupt performance.
  • Business changes, such as new legislation, force rapid system updates.
Figure 9.6 — The emergency repair process

Emergency fixes are fast but risky: they may leave the requirements, design, and code inconsistent. Repeated urgent patches can accelerate software aging, making future maintenance harder and more expensive.

Agile Methods and Evolution

Agile methods, based on incremental development, naturally extend into software evolution. Automated regression testing and customer involvement ensure smooth adaptation of systems. However, problems can occur during team handovers:

  • When a development team uses agile methods but the evolution team prefers a plan-based approach, documentation gaps can hinder evolution.
  • When development was plan-based but the evolution team wants agile, reengineering may be necessary to add automated tests and refactor code.

Poole and Huisman (2001) report success in transitioning from a plan-based approach to Extreme Programming (XP) for maintaining a large system, once reengineering improved its structure.