0% found this document useful (0 votes)
4 views35 pages

Software Evolution and Change Management

The document discusses software evolution, emphasizing the inevitability of software change due to emerging requirements, error repairs, and environmental adaptations. It outlines various stages of software evolution, including operational use, servicing, and phase-out, as well as the importance of maintenance and re-engineering. Additionally, it highlights the role of agile methods in facilitating seamless transitions from development to evolution and presents Lehman's laws that govern program evolution dynamics.

Uploaded by

sunilstha68
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views35 pages

Software Evolution and Change Management

The document discusses software evolution, emphasizing the inevitability of software change due to emerging requirements, error repairs, and environmental adaptations. It outlines various stages of software evolution, including operational use, servicing, and phase-out, as well as the importance of maintenance and re-engineering. Additionally, it highlights the role of agile methods in facilitating seamless transitions from development to evolution and presents Lehman's laws that govern program evolution dynamics.

Uploaded by

sunilstha68
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Software Evolution

1
Review {Testing}

 Validation & Verification


 Inspection & Testing
 Stages of Testing
 Development Testing: Unit, Component and System Testing
 Release Testing: Requirements testing, Performance Testing
 User Testing: Alpha, Beta and Acceptance Testing
 Test Driven Development

2
3
Evolution

Windows 3.11 Windows 98 Windows XP

Windows 10 4
Software change

 Software change is inevitable


 New requirements emerge when the software is used;
 Errors must be repaired;
 New computers and equipment is added to the system;
 The performance or reliability of the system may have to be improved.
 Systems are tightly coupled with their environment. When a system is installed
in an environment it changes that environment and therefore changes the
system requirements.
 Systems MUST be changed if they are to remain useful in an environment.
 A key problem for all organizations is implementing and managing change to
their existing software systems.

5
O
r
g Importance of evolution
a
n
i
z
a
t
i
o
n
s

h
a
v
e

h 6
u
A spiral model of development and evolution

7
Stages of Software

8
Stages of Software

 Evolution
 The stage in a software system’s life cycle where it is in operational use and is evolving
as new requirements are proposed and implemented in the system.
 Servicing
 At this stage, the software remains useful but the only changes made are those required
to keep it operational i.e. bug fixes and changes to reflect changes in the software’s
environment. No new functionality is added.
 Phase-out
 The software may still be used but no further changes are made to it.

9
S
o
f Evolution processes
t
w
a
r
e

e
v
o
l
u
t
i
o
n 10
Change identification and evolution processes

11
The software evolution process

12
Change implementation

13
Change implementation

 Iteration of the development process where the revisions to the system are
designed, implemented and tested.
 The first stage of change implementation may involve program
understanding, especially if the original system developers are not
responsible for the change implementation.
 During the program understanding phase, you have to understand how the
program is structured, how it delivers functionality and how the proposed
change might affect the program.

14
U
r
g Urgent change requests
e
n
t

c
h
a
n
g
e
s

m
a
y 15
The emergency repair process

16
Agile methods and evolution

 Agile methods are based on incremental development so the transition from


development to evolution is a seamless one.
 Evolution is simply a continuation of the development process based on frequent system
releases.
 Changes may be expressed as additional user stories.

17
P
r
o Program evolution dynamics
g
r
a
m

e
v
o
l
u
t
i
o
n

d
y 18
n
Lehman’s laws
Law Description

A program that is used in a real-world environment must necessarily


Continuing change change, or else become progressively less useful in that environment.

As an evolving program changes, its structure tends to become more


Increasing complexity complex. Extra resources must be devoted to preserving and simplifying the
structure.

Program evolution is a self-regulating process. System attributes such as


Large program evolution size, time between releases, and the number of reported errors is
approximately invariant for each system release.

Organizational stability Over a program’s lifetime, its rate of development is approximately constant
and independent of the resources devoted to system development.

19
Lehman’s laws
Law Description

Over the lifetime of a system, the incremental change in each


Conservation of familiarity
release is approximately constant.

The functionality offered by systems has to continually increase to


Continuing growth
maintain user satisfaction.

Declining quality The quality of systems will decline unless they are modified to
reflect changes in their operational environment.

Evolution processes incorporate multi-agent, multi-loop feedback


Feedback system systems and you have to treat them as feedback systems to
achieve significant product improvement.

20
M
o
d Software maintenance
i
f
y
i
n
g

p
r
o
g
r
a 21
m
M
a
i Types of maintenance
n
t
e
n
a
n
c
e

t
o

r
e
p 22
a
U
s
u Maintenance costs
a
l
l
y

g
r
e
a
t
e
r

t
h 23
a
Maintenance cost factors

 Team stability
 Maintenance costs are reduced if the same staff are involved with them for some time.
 Contractual responsibility
 The developers of a system may have no contractual responsibility for maintenance so
there is no incentive to design for future change.
 Staff skills
 Maintenance staff are often inexperienced and have limited domain knowledge.
 Program age and structure
 As programs age, their structure is degraded and they become harder to understand and
change.

24
R
e
- System re-engineering
s
t
r
u
c
t
u
r
i
n
g

o
r
25
r
R
e
d Advantages of reengineering
u
c
e
d

r
i
s
k
 T
h
e
r
e

i 26
s
S
o
u Reengineering process activities
r
c
e

c
o
d
e

t
r
a
n
s
l 27
a
T
h
e Reengineering cost factors

q
u
a
l
i
t
y

o
f

t
h
e

s 28
o
Preventative maintenance by refactoring

 Refactoring is the process of making improvements to a program to slow


down degradation through change.
 You can think of refactoring as ‘preventative maintenance’ that reduces the
problems of future change.
 Refactoring involves modifying a program to improve its structure, reduce its
complexity or make it easier to understand.
 When you refactor a program, you should not add functionality but rather
concentrate on program improvement.

29
Refactoring and reengineering

 Re-engineering takes place after a system has been maintained for some
time and maintenance costs are increasing.
 Refactoring is a continuous process of improvement throughout the
development and evolution process. It is intended to avoid the structure and
code degradation that increases the costs and difficulties of maintaining a
system.

30
O
r
g Legacy system management
a
n
i
s
a
t
i
o
n
s

t
h
a
t 31
L
o
w Legacy system categories

q
u
a
l
i
t
y
,

l
o
w

b 32
u
A
s
s Business value assessment
e
s
s
m
e
n
t

s
h
o
u
l
d
33
t
Issues in business value assessment

 The use of the system


 If systems are only used occasionally or by a small number of people, they may have a
low business value.
 The business processes that are supported
 A system may have a low business value if it forces the use of inefficient business
processes.
 System dependability
 If a system is not dependable and the problems directly affect business customers, the
system has a low business value.
 The system outputs
 If the business depends on system outputs, then the system has a high business value.

34
B
u
s System quality assessment
i
n
e
s
s

p
r
o
c
e
s
s

a 35
s

Common questions

Powered by AI

Refactoring is considered a form of preventative maintenance because it involves making systematic improvements to a program's structure to prevent code degradation and reduce future maintenance difficulties. The primary goals of refactoring are to enhance program readability and maintainability by simplifying complex code, improving the system's architecture, and making it easier to understand without adding new functionalities. This proactive approach helps to manage complexity and preserve software quality over time .

Program understanding is crucial in the change implementation process as it involves comprehending the existing software structure, functionalities, and potential impacts of proposed changes. This understanding is vital for effective software evolution as it ensures that modifications align with current system designs and objectives without causing unforeseen issues. Without a complete grasp of the system, even small changes can lead to significant errors or system downtimes. Familiarity with the software architecture enhances the effectiveness and efficiency of implementing changes, highlighting the importance of documentation and knowledge retention .

In agile methods, the transition from development to evolution is seamless because development is viewed as a continuous cycle. Agile approaches, such as incremental development, naturally lend themselves to evolutionary processes by enabling frequent system releases that incorporate user feedback. This method allows for the constant iteration of software that aligns with changing user needs and technological advancements, ensuring longevity and relevance. The frequent updates and user engagement foster a system that can adapt over time without becoming obsolete .

Urgent change requests differ from standard change implementation processes as they require a rapid response due to their immediate nature and potential impact on the system's functionality or business operations. These requests bypass the usual, extensive planning and testing stages associated with standard change implementations. Instead, they often involve quick evaluations to implement necessary fixes rapidly, minimizing disruption in services. The primary goal is to address critical issues without the delay of comprehensive development cycles .

Maintenance cost factors like team stability and program age significantly affect the cost-efficiency of software systems. Team stability reduces training and transition costs, as consistent staffing tends to lead to better knowledge retention and more efficient problem-solving. Conversely, a stable team familiar with the system can reduce error rates and expedite effective maintenance. Meanwhile, program age often correlates with increased structural complexity and degraded code quality, which elevate maintenance efforts and costs due to the challenges of understanding and modifying outdated or poorly documented code. Together, these factors suggest that maintaining a stable team and updating system architectures can enhance cost-efficiency by streamlining maintenance processes and reducing the need for extensive modifications .

Organizational stability suggests that the rate of software development remains constant over time, which influences the development process by encouraging predictable and steady work cycles, rather than rapid, unsustainable development pushes. Conservation of familiarity implies that changes to the software system in each release are kept incremental and manageable, helping maintain developer and user habituation to the system's operational dynamics. These laws emphasize the need for measured and consistent development practices that prioritize gradual improvements over radical changes, supporting long-term system stability and user satisfaction .

Lehman's Laws of Software Evolution provide several insights into the necessity for ongoing software maintenance. The law of 'Continuing Change' states that software must evolve to remain useful, implying continuous maintenance. 'Increasing Complexity' suggests that as software evolves, its complexity rises, necessitating maintenance to manage this complexity. 'Continuing Growth' and 'Declining Quality' highlight the need for maintenance to address the growing functional demands and declining quality. 'Feedback System' indicates that evolution processes involve feedback to improve product performance, further supporting the need for structured maintenance activities .

The tight coupling of software systems with their environments means that any change in the environment necessitates adjustments in the software to maintain its usability and relevance. As environments evolve due to new hardware, user needs, or market demands, the software must change in response. This interrelationship implies that software systems will require continual updates and modifications to adapt to these external shifts, stressing the importance of proactive and flexible change management strategies to maintain alignment and functionality .

Organizations managing legacy systems face several challenges, including high maintenance costs due to outdated technology, integration difficulties with modern systems, and a lack of skilled personnel familiar with older technologies. These systems can also be cumbersome and inefficient, negatively impacting business processes and adaptability. Consequently, legacy systems can detract from business value by limiting operational efficiency and increasing the cost of scalability and innovation, especially if they hinder the adoption of new technologies that offer competitive advantages .

The stages of software evolution are evolution, servicing, and phase-out. During the evolution stage, the software is in operational use and changes as new requirements are implemented. In the servicing stage, the software is maintained operationally without new features, focusing on bug fixes and adapting to environmental changes. During phase-out, the software is still used but no further changes are made. These stages impact software maintenance as they determine the type and extent of maintenance activity needed. During evolution, extensive modifications and feature additions are commonplace, whereas servicing focuses on maintenance that ensures continued operation without significant changes.

You might also like