Bse 3105 lecture 2- software change
-
Upload
alonzee-tash -
Category
Engineering
-
view
26 -
download
0
Transcript of Bse 3105 lecture 2- software change
![Page 1: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/1.jpg)
Software change
Managing the processes of software system change
1
![Page 2: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/2.jpg)
Objectives
To explain different strategies for changing software systems
Software maintenance Architectural evolution Software re-engineering
To explain the principles of software maintenance
2
![Page 3: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/3.jpg)
Software change Software change is inevitable
New requirements emerge when the software is used
The business environment changes Errors must be repaired New equipment must be accommodated The performance or reliability may have to be
improved A key problem for organisations is implementing and
managing change to their legacy systems
3
![Page 4: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/4.jpg)
Software change strategies Software maintenance
Changes are made in response to changed requirements but the fundamental software structure is stable
Architectural transformation The architecture of the system is modified generally from a
centralized architecture to a distributed architecture Software re-engineering
No new functionality is added to the system but it is restructured and reorganized to facilitate future changes
These strategies may be applied separately or together
4
![Page 5: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/5.jpg)
Program evolution dynamics is the study of the processes of system change
After major empirical study, Lehman and Belady proposed that there were a number of ‘laws’ which applied to all systems as they evolved
There are sensible observations rather than laws. They are applicable to large systems developed by large organisations. Perhaps less applicable in other cases
Program evolution dynamics
5
![Page 6: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/6.jpg)
Lehman’s laws of Software Evolution
Lehman suggested eight laws of S/w evolution[Draw graphs for laws 1 and 2].
Continuing change: A program that is used in a real-world environment necessarily must change or become progressively less useful in that environment.
Increasing complexity: As an evolving program changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure.
Large program evolution: Program evolution is a self-regulating process. System attributes such as 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.
cc
6
![Page 7: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/7.jpg)
Lehman’s laws of Software Evolution-Cont’d
• Conservation of familiarity: Over the lifetime of a system, the incremental change in each releases is approximately constant.
• Continuing growth: The functionality offered by systems has to continually increase to maintain user satisfaction
• Declining quality: The quality of systems will appear to be declining unless they are adapted to changes in their operational environment.
• Feedback system: Evolution processes incorporate multi-agent, multi-loop feedback systems and you have to treat them as feedback systems to achieve significant product improvement.
7
![Page 8: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/8.jpg)
Applicability of Lehman’s laws
This has not yet been established They are generally applicable to large, tailored
systems developed by large organisations It is not clear how they should be modified for
Shrink-wrapped software products Systems that incorporate a significant number of
COTS components Small organizations Medium sized systems
8
![Page 9: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/9.jpg)
Modifying a program after it has been put into use
Maintenance does not normally involve major changes to the system’s architecture
Changes are implemented by modifying existing components and adding new components to the system
Software maintenance
9
![Page 10: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/10.jpg)
Maintenance is Expensive … but is it necessary?
The solution to the problem of software maintenance is to build systems properly in the first place, right?
Perfection seems to be unattainable
Even if perfection were attainable, software is affected by other changes like;
• Technological changes
– E.g. tapes vs. hard disks• Changes to laws and government regulations
– E.g. data protection act, taxation ...• Changes to the business environment
– E.g. need to deal with new, or much larger numbers of, customers/sales/products/...
– E.g. e-commerce• Changes to organizational structure
– E.g. company mergers[case of Airtel and Warid] 10
![Page 11: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/11.jpg)
The system requirements are likely to change while the system is being developed because the environment is changing. Therefore a delivered system won't meet its requirements!
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 maintained therefore if they are to remain useful in an environment
Maintenance is inevitable
11
![Page 12: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/12.jpg)
When is S/W maintenance needed?
Maintenance to repair software faults
– Coding errors are usually relatively cheap to correct
– Design errors are more expensive as they may involve rewriting several program components
– Requirements errors are the most expensive to repair because of the extensive system redesign that may be necessary
Maintenance to adapt the software to a new operating environment
– This type of maintenance is required when some aspect of the system’s environment such as the hardware, the platform operating systems or other support software changes
– The application system must be modified to adapt it to cope with these environmental changes
Maintenance to add to or modify the system's functionality
– This type of maintenance is necessary when the system requirements change in response to organizational or business change
– The scale of the changes required to the software is often much grater that the other types of maintenance
12
![Page 13: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/13.jpg)
Types of Software Changes done in Maintenance
• Studies reveal 4 types of change
• Corrective change
– correcting faults in system behavior– caused by errors in coding, design or requirements
• Adaptive change
– due to changes in operating environment– e.g., different hardware or Operating System
• Perfective change
– due to changes in requirements– Often triggered by organizational, business or user learning
• Preventive change
– e.g., dealing with legacy systems (legacy systems are these older systems that remain vital to the organization)
• Exercise: define each of the above, and find at least two cases of software projects for each of them where it has been used. Also find out which of the 4 is common. 13
![Page 14: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/14.jpg)
Managing S/W Maintenance
•
• Corrective:
– Requires maintenance strategy preferably negotiated contract between supplier and customer(s)
– Policies for reporting and fixing errors; auditing of process
• Perfective:
– Should be treated as development (e.g., requirements, specification, design, testing, etc.)
– Iterative (or evolutionary) development approach best suited
– Risks: drift, shift, creep, ooze, bloat, etc.
– When does design or development stop?
• Adaptive and Preventive:
– Can anticipate, schedule, monitor and manage, etc. 14
![Page 15: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/15.jpg)
Distribution of maintenance effort
Question: What are the reasons behind the percentages?
15
![Page 16: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/16.jpg)
Spiral maintenance model
16
![Page 17: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/17.jpg)
Usually greater than development costs (2% to 100% depending on the application)
Affected by both technical and non-technical factors
Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult.
Ageing software can have high support costs (e.g. old languages, compilers etc.)
Maintenance costs
17
![Page 18: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/18.jpg)
Development/maintenance costs
18
![Page 19: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/19.jpg)
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
Maintenance cost factors
19
![Page 20: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/20.jpg)
Evolutionary software
Rather than think of separate development and maintenance phases, evolutionary software is software that is designed so that it can continuously evolve throughout its lifetime
20
![Page 21: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/21.jpg)
The maintenance process
NB: The arrow from “system release” to “change request” means that a change can cause a new change request.
21
![Page 22: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/22.jpg)
Change requests Change requests are requests for system changes
from users, customers or management In principle, all change requests should be carefully
analyzed as part of the maintenance process and then implemented
In practice, some change requests must be implemented urgently
Fault repair Changes to the system’s environment Urgently required business changes
22
![Page 23: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/23.jpg)
Change implementation
23
![Page 24: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/24.jpg)
Emergency repair
24
![Page 25: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/25.jpg)
Maintenance prediction Maintenance prediction is concerned with assessing
which parts of the system may cause problems and have high maintenance costs
Change acceptance depends on the maintainability of the components affected by the change
Implementing changes degrades the system and reduces its maintainability
Maintenance costs depend on the number of changes and costs of change depend on maintainability
25
![Page 26: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/26.jpg)
Maintenance prediction
26
![Page 27: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/27.jpg)
Change prediction
Predicting the number of changes requires understanding of the relationships between a system and its environment
Tightly coupled systems require changes whenever the environment is changed. Recall that in tightly coupled systems, one module can heavily rely on another module such that a change in one module means a change in the other module. For example if they are sharing external variables.
Factors influencing this relationship are Number and complexity of system interfaces. Like how
many modules will need to be changed when one module is changed?
Number of inherently volatile system requirements The business processes where the system is used
27
![Page 28: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/28.jpg)
Complexity metrics Predictions of maintainability can be made by
assessing the complexity of system components Studies have shown that most maintenance effort is
spent on a relatively small number of system components[possibly due to the maintainability of those few components]
Complexity depends on Complexity of control structures Complexity of data structures Procedure and module size
28
![Page 29: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/29.jpg)
Process metrics Process measurements may be used to assess
maintainability Number of requests for corrective maintenance.
E.g. How many errors have been reported?
Average time required for impact analysis Average time taken to implement a change
request Number of outstanding change requests
If any or all of these is increasing, this may indicate a decline in maintainability
29
![Page 30: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/30.jpg)
Architectural evolution There is a need to convert many legacy systems
from a centralized architecture to a client-server architecture
Change drivers Hardware costs. Servers are cheaper than
mainframes User interface expectations. Users expect
graphical user interfaces[not just black and white screens]
Distributed access to systems. Users wish to access the system from different, geographically separated, computers 30
![Page 31: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/31.jpg)
Distribution factors (i.e factors that affect the shift
from centralized to distributed architecture)
31
![Page 32: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/32.jpg)
Key points
Software change strategies include software maintenance, architectural evolution and software re-engineering
Lehman’s Laws are invariant [or true] relationships that affect the evolution of a software system
Maintenance types are Maintenance for repair Maintenance for a new operating environment Maintenance to implement new requirements
32
![Page 33: Bse 3105 lecture 2- software change](https://reader031.fdocuments.us/reader031/viewer/2022032503/55beaa8abb61eb80198b45c3/html5/thumbnails/33.jpg)
Key points
The costs of software change usually exceed the costs of software development
Factors influencing maintenance costs include staff stability, the nature of the development contract, skill shortages and degraded system structure
Architectural evolution is concerned with evolving centralised to distributed architectures
33