Lectures Software Engineering - Chapter 27: Software change

39 trang hoanguyen 3900

Download

Bạn đang xem 20 trang mẫu của tài liệu "Lectures Software Engineering - Chapter 27: Software change", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

lectures_software_engineering_chapter_27_software_change.ppt

Nội dung text: Lectures Software Engineering - Chapter 27: Software change

Software change l Managing the processes of software system change ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 1
Objectives l To explain different strategies for changing software systems • Software maintenance • Architectural evolution • Software re-engineering l To explain the principles of software maintenance l To describe the transformation of legacy systems from centralised to distributed architectures ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 2
Topics covered l Program evolution dynamics l Software maintenance l Architectural evolution ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 3
Software change l 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 l A key problem for organisations is implementing and managing change to their legacy systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 4
Software change strategies l Software maintenance • Changes are made in response to changed requirements but the fundamental software structure is stable l Architectural transformation • The architecture of the system is modified generally from a centralised architecture to a distributed architecture l Software re-engineering • No new functionality is added to the system but it is restructured and reorganised to facilitate future changes l These strategies may be applied separately or together ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 5
Program evolution dynamics l Program evolution dynamics is the study of the processes of system change l After major empirical study, Lehman and Belady proposed that there were a number of ‘laws’ which applied to all systems as they evolved l There are sensible observations rather than laws. They are applicable to large systems developed by large organisations. Perhaps less applicable in other cases ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 6
Applicability of Lehman’s laws l This has not yet been established l They are generally applicable to large, tailored systems developed by large organisations l It is not clear how they should be modified for • Shrink-wrapped software products • Systems that incorporate a significant number of COTS components • Small organisations • Medium sized systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 8
Software maintenance l Modifying a program after it has been put into use l Maintenance does not normally involve major changes to the system’s architecture l Changes are implemented by modifying existing components and adding new components to the system ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 9
Maintenance is inevitable l 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! l 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. l Systems MUST be maintained therefore if they are to remain useful in an environment ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 10
Types of maintenance l Maintenance to repair software faults • Changing a system to correct deficiencies in the way meets its requirements l Maintenance to adapt software to a different operating environment • Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation l Maintenance to add to or modify the system’s functionality • Modifying the system to satisfy new requirements ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 11
Maintenance costs l Usually greater than development costs (2* to 100* depending on the application) l Affected by both technical and non-technical factors l Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult. l Ageing software can have high support costs (e.g. old languages, compilers etc.) ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 14
Maintenance cost factors l Team stability • Maintenance costs are reduced if the same staff are involved with them for some time l Contractual responsibility • The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change l Staff skills • Maintenance staff are often inexperienced and have limited domain knowledge l Program age and structure • As programs age, their structure is degraded and they become harder to understand and change ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 16
Evolutionary software l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 17
Change requests l Change requests are requests for system changes from users, customers or management l In principle, all change requests should be carefully analysed as part of the maintenance process and then implemented l In practice, some change requests must be implemented urgently • Fault repair • Changes to the system’s environment • Urgently required business changes ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 19
Maintenance prediction l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 22
Change prediction l Predicting the number of changes requires and understanding of the relationships between a system and its environment l Tightly coupled systems require changes whenever the environment is changed l Factors influencing this relationship are • Number and complexity of system interfaces • Number of inherently volatile system requirements • The business processes where the system is used ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 24
Complexity metrics l Predictions of maintainability can be made by assessing the complexity of system components l Studies have shown that most maintenance effort is spent on a relatively small number of system components l Complexity depends on • Complexity of control structures • Complexity of data structures • Procedure and module size ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 25
Process metrics l Process measurements may be used to assess maintainability • Number of requests for corrective maintenance • Average time required for impact analysis • Average time taken to implement a change request • Number of outstanding change requests l If any or all of these is increasing, this may indicate a decline in maintainability ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 26
Architectural evolution l There is a need to convert many legacy systems from a centralised architecture to a client-server architecture l Change drivers • Hardware costs. Servers are cheaper than mainframes • User interface expectations. Users expect graphical user interfaces • Distributed access to systems. Users wish to access the system from different, geographically separated, computers ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 27
Legacy system structure l Ideally, for distribution, there should be a clear separation between the user interface, the system services and the system data management l In practice, these are usually intermingled in older legacy systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 29
Distribution options l The more that is distributed from the server to the client, the higher the costs of architectural evolution l The simplest distribution model is UI distribution where only the user interface is implemented on the server l The most complex option is where the server simply provides data management and application services are implemented on the client ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 33
User interface distribution l UI distribution takes advantage of the local processing power on PCs to implement a graphical user interface l Where there is a clear separation between the UI and the application then the legacy system can be modified to distribute the UI l Otherwise, screen management middleware can translate text interfaces to graphical interfaces ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 35
Key points l Software change strategies include software maintenance, architectural evolution and software re-engineering l Lehman’s Laws are invariant relationships that affect the evolution of a software system l Maintenance types are • Maintenance for repair • Maintenance for a new operating environment • Maintenance to implement new requirements ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 38
Key points l The costs of software change usually exceed the costs of software development l Factors influencing maintenance costs include staff stability, the nature of the development contract, skill shortages and degraded system structure l Architectural evolution is concerned with evolving centralised to distributed architectures l A distributed user interface can be supported using screen management middleware ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27 Slide 39