C H A P T E R 9
Software development does not stop after it has been delivered but continues throughout the lifetime of the system. After a system has been deployed, it has to change, for sure, if it has to remain useful. Business changes and changes to user expectations generate new requirements for the existing software. Parts of the software may have to be modified to correct errors that are found in operation, to adapt it for changes in its hardware and software platforms, and to improve its performance and other non-functional characteristics.
Evolution of a system may rarely be considered in isolation. Changes to the environment lead to system change that may trigger further environment changes. Of course, the fact that systems have to evolve in a systems-rich environment often increases the difficulties and costs of evolution. In addition to understanding and analyzing the impact of a proposed change on the system itself, you may have to assess how this affects other systems in the operational environment.
Software cost a lot of money so that a company has to use it for many years to get a return on the investment. Of course, requirements of the installed system change as the business and its environment change. Therefore, new releases of the systems, incorporating changes and updates, have to be created at regular intervals.
You should, therefore, think of software engineering as a spiral process with requirements, design, implementation and testing going on throughout the lifetime of the system. You start by creating release1 of the system. Once delivered, changes are proposed and the development of release2 starts immediately. In fact, the need for evolution may become obvious even before the system is deployed so that later releases of the system may be under development before the current version is released.
This model of evolution implies that a single organization is responsible for both the initial development as well as the evolution of the software. Most packaged software products are developed using this approach. For custom software, a different approach is usually used. A company develops software for a customer and the customer’s own software development staff then takes over the system. Alternatively, the software customer can issue a contract to a different company for system support and evolution.
Fig. 9.1: A Spiral Model of Development and Evolution
In this case, there are likely to be discontinuities in the spiral process. Requirements and design documents may not be passed from one company to another. Companies may merge or reorganize and inherit software from other companies and then find this has to be changed. When the transition from development to evolution is not indefinite, the process of changing the software after delivery is called software maintenance.
An alternate view of software evolution life cycle is shown below. In this view, evolution and servicing are distinguished. Evolution is the phase in which significant changes to the software architecture and functionality are made. During servicing, the only changes that are made are relatively small, essential changes.
Fig. 9.2: Evolution and Servicing
During evolution the software is used successfully and there is a constant stream of proposed requirements changes. However, as the software is modified, its structure starts to degrade and changes become more and more expensive. This happens after a few years of use when environmental changes, such as hardware and operating systems, are also required. At some stage in the life cycle, the software reaches a transition point where significant changes, implementing new requirements, become less costly.
At that stage, the software moves from evolution to servicing. During the servicing phase, the software is still used but only tactical changes are made to it. During this stage, the company is usually considering about replacing the software. It is still used but at a final point, the phase-out, no further changes are made to it and so, users have to work around any problems they discover.
Software evolution processes vary depending on the type of software being maintained, the development processes used in an organization and the skills of people involved. In some organizations, evolution may be an informal process where change requests come from the conversations between system users and developers. In other companies, it is a formalized process with structured documentation produced at each stage in the process.
System change proposals are the driver for system evolution in all organizations. Change proposals may come from existing requirements that have not been implemented in the released system, requests for new requirements, bug reports from systems stakeholders and new ideas for software improvement from the software development team. The processes of change identification and system evolution are cyclic and continue throughout the lifetime of a system as shown in the following figure.
Fig. 9.3: Change identification and evolution processes
Change proposals should be linked to components of the system that have to be modified to implement these systems. This allows the cost and impact of the change to be assessed. This is part of the general process of change management, which also should ensure that the correct versions of components are included in each system release.
The following figure shows an overview of the evolution process.
Fig. 9.4: The software evolution process
The process includes the fundamental activities of change analysis, release planning, system implementation and releasing a system to customers. The cost and impact of these changes are assessed to see how much of the system is affected by the change and how much it will cost to implement the change. If the proposed changes are accepted, a new release of the system is planned. During release planning, all proposed changes (fault repair, adaptation, new functionality) are considered. A decision is then made based on the changes which are to be implemented in the next version of the system. The changes are implemented and validated and a new version of the system is released. The process then iterates with a new set of changes proposed for the next release.
You can think of the change implementation as an iteration of the development process, where revisions to the system are designed, implemented and tested. However, the critical difference is that the first stage of change implementation may involve understanding the program if the system developers are not responsible for the change implementation. During this program understanding phase, you have to understand how the program is structured, how it delivers the functionality of the program and how the proposed change might affect the program. You need this understanding to make sure that the proposed change does not cause new problems when it is introduced in the existing system.
Ideally, the change implementation of this process should modify the system specification, design and implementation to reflect the changes to the system as shown in Fig. 9.5 below. New requirements that reflect the system changes are proposed, analyzed and validated. System components are redesigned and implemented and the system is retested. If appropriate, prototyping of the proposed changes may be carried out as part of the change analysis process.
During the evolution process, the requirements are analyzed in detail and implications of the changes emerge that were not apparent in the earlier stage analysis process. This means that the proposed changes may be modified and further customer discussions may be required before they are implemented.
Change requests sometimes relate to system problems that have to be tackled urgently. These urgent changes can arise for three reasons:
a) If a serious system fault occurs that has to be repaired to allow normal operation to continue.
b) If changes to the system operating environment have unexpected effects that disrupt normal operation.
c) If there are unanticipated changes to the business running the system such as the emergence of new competitors or the introduction of new legislation that affects the system.
Fig. 9.5: Change Implementation
In these cases, the need to make the change quickly may mean you may not be able to follow the formal change process. Rather than modify the requirements and design, you make a quick emergency fix to the program to solve the immediate problem. This is illustrated in the following figure.
Fig. 9.6: The emergency repair process
However, the danger is that the requirements, design and code become inconsistent. Although you desire to document the change in requirements and design, further emergency fixes to the software may still be needed. These take priority over documentation. Ultimately, the original change is forgotten and the system documentation and code are never realigned.
Emergency system repairs will have to be implemented as quickly as possible. You choose a quick and workable solution rather than the best solution as far as system structure is concerned. This accelerates the process of software ageing so that future changes gradually become even more difficult and maintenance costs increase.
Agile methods and processes, as discussed in chapter 4, may be used for program evolution and program development. However, problems arise in situations where there is a handover from a development team to a separate team responsible for evolution. Two such problematic situations are:
1) The development team has used agile methods but the evolution team prefers a plan-based approach. The evolution team may expect detailed documentation to support evolution but this is rarely done in an agile approach.
2) The development team has used a plan-based approach but the evolution team prefers agile methods. In this case, some reengineering may have to be done to improve the code before it can be used in an agile development process.