Page 256 -

9.1 Evolution processes 239

Proposed Requirements Requirements Software
Figure 9.5 Change Changes Analysis Updating Development
implementation

Figure 9.6 The Change Analyze Modify Deliver Modified
emergency repair Requests Source Code Source Code System
process

2. If changes to the systems operating environment have unexpected effects that
disrupt normal operation.

3. 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.

In these cases, the need to make the change quickly means that you may not be
able to follow the formal change analysis process. Rather than modify the require-
ments and design, you make an emergency fix to the program to solve the immedi-
ate problem (Figure 9.6). However, the danger is that the requirements, the software
design, and the code become inconsistent. Although you may intend to document
the change in the requirements and design, additional emergency fixes to the soft-
ware may then be needed. These take priority over documentation. Eventually, the
original change is forgotten and the system documentation and code are never
realigned.
Emergency system repairs usually have to be completed as quickly as possible.
You chose a quick and workable solution rather than the best solution as far as sys-
tem structure is concerned. This accelerates the process of software ageing so that
future changes become progressively more difficult and maintenance costs increase.
Ideally, when emergency code repairs are made the change request should remain
outstanding after the code faults have been fixed. It can then be reimplemented more
carefully after further analysis. Of course, the code of the repair may be reused. An
alternative, better solution to the problem may be discovered when more time is
available for analysis. In practice, however, it is almost inevitable that these improve-
ments will have a low priority. They are often forgotten and, if further system
changes are made, it then becomes unrealistic to redo the emergency repairs.
Agile methods and processes, discussed in Chapter 3, may be used for program
evolution as well as program development. In fact, because these methods are based
on incremental development, making the transition from agile development to post-
delivery evolution should be seamless. Techniques such as automated regression testing
are useful when system changes are made. Changes may be expressed as user stories
and customer involvement can prioritize changes that are required in an operational
system. In short, evolution simply involves continuing the agile development process.