For a software developer, there is nothing better than starting a new project on “undeveloped land”. In reality, however, this rarely happens. Which is why it is all the more surprising that the particular circumstances in a long-term project and the structures within existing applications are so rarely subjected to a structured assessment. Or at least it looks that way, although there is, in fact, a subject area called “software evolution” that addresses this precise issue.
Figure 1 shows that the life cycle of a complex software system is divided into several stages. Often, the period of evolution is left out, and it is assumed that following the initial development stage, the only services required are services that preserve the value, such as debugging.
In practice, however, the very first contact with the user already gives rise to a number of new requirements, the implementation of which needs to be synchronized with the daily production tasks. Instead of reaching a certain level of development that just needs to be maintained from then on, the software continuously evolves based on its utilization. This becomes obvious in particular if you consider the tasks during operation over a period of many years.
Figure 2 shows the software developers’ main tasks that arise over time during software use. Obviously, everything starts with the development. Over time, stabilizing measures such as debugging become increasingly important. As the number of users increases, so does the need to use any potential for optimization, even as new features are still being implemented. After a few years at the latest, sections or all of the software will need to be upgraded, e.g. because the underlying technologies have fundamentally changed, or because the look and the user interface need to be improved.
When the system needs to be upgraded, there are several different ways to do so. The most obvious solution, developing entirely new software based on the experience gained from the existing system, requires the greatest effort and should therefore only be chosen in exceptional cases. Redesigning individual parts appears to be much more sensible, but that does not mean that only certain modules or components of the system are replaced. It can also mean that features or function groups are transferred to a new, streamlined software system and provided as a parallel system. Whichever option you choose, you have to ensure that the existing system continues to work correctly during the upgrade.
Already during the stabilization process, but upon optimization of the system at the latest, you will notice necessary changes that do not necessarily generate an immediate added value for the end user. This is why a continuous analysis of the system and assessment of possible tasks are essential for a target-oriented evolution. Otherwise, you run the risk of unnecessary adjustments and consequently, unnecessary costs.
This post was written by:
