Software Change
It is impossible to produce systems of any size which do not need to be changed. Once
software is put into use, new requirements emerge and existing requirements change as the
business running that software changes. Parts of the software may have to be modified to
correct errors that are found in operation, improve its performance or other non-functional
characteristics. All of this means that, after delivery, software systems always evolve in
response to demands for change.
Software change is very important because organizations are now completely dependent on
their software systems and have invested millions of dollars in these systems. Their systems
are critical business assets and they must invest in system change to maintain the value of
these assets. A key problem for organizations is implementing and managing change to their
legacy systems so that they continue to support their business operations.
There are a number of different strategies for software change (Warren, 1998):
1. Software maintenance: Changes to the software are made in response to changed
requirements but the fundamental structure of the software remains stable. This is
the most common approach used to system change
2. Architectural transformation: This is a more radical approach to software change
then maintenance as it involves making significant changes to the architecture of
the software system. Most commonly, systems evolve from a centralized, data-
centric architecture to a client-server architecture.
3. Software re-engineering: This is different from other strategies in that no new
functionality is added to the system. Rather, the system is modified to make it
easier to understand and change. System re-engineering may involve some
structural modifications but does not usually involve major architectural change.
