Page 60 -
P. 60
2.3 Coping with change 43
Requirements System System Detailed
Specification Specification Design Design
System Sub-System Module and
Acceptance Integration Integration Unit Code
Test Plan
Test Plan Test Plan and Test
Acceptance System Sub-System
Service
Test Integration Test Integration Test
2.2.4 Software evolution
Figure 2.7
Testing phases The flexibility of software systems is one of the main reasons why more and more
in a plan-driven
software process software is being incorporated in large, complex systems. Once a decision has been
made to manufacture hardware, it is very expensive to make changes to the hardware
design. However, changes can be made to software at any time during or after the
system development. Even extensive changes are still much cheaper than correspon-
ding changes to system hardware.
Historically, there has always been a split between the process of software devel-
opment and the process of software evolution (software maintenance). People think
of software development as a creative activity in which a software system is devel-
oped from an initial concept through to a working system. However, they sometimes
think of software maintenance as dull and uninteresting. Although the costs of main-
tenance are often several times the initial development costs, maintenance processes
are sometimes considered to be less challenging than original software development.
This distinction between development and maintenance is increasingly irrelevant.
Hardly any software systems are completely new systems and it makes much more
sense to see development and maintenance as a continuum. Rather than two separate
processes, it is more realistic to think of software engineering as an evolutionary
process (Figure 2.8) where software is continually changed over its lifetime in
response to changing requirements and customer needs.
2.3 Coping with change
Change is inevitable in all large software projects. The system requirements change
as the business procuring the system responds to external pressures and management
priorities change. As new technologies become available, new design and implemen-
tation possibilities emerge. Therefore whatever software process model is used, it is
essential that it can accommodate changes to the software being developed.