CS 425/625 Software Engineering Software Evolution Based on Chapter 21

CS 425/625 Software Engineering Software Evolution Based on Chapter 21 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8th Ed., Addison-Wesley, 2006 and on the “Ch21” PowerPoint presentation available at the book’s web-site November 12, 2008 1 / 24

Outline Introduction Program Evolution Dynamics Software Maintenance 2 / 24 Overview Prediction Evolution Processes Legacy Systems

Introduction . Software evolves continuously due to demands for changes: 3 / 24 New requirements surface Existing requirements need be modified Errors found need be fixed In some cases 90% of software costs are evolution costs When the transition from development to evolution is not smooth, changing software after delivery is called software maintenance

.Introduction A spiral model of development and evolution [Fig. 21.1, SE-8] Implemention Specification Start Release 1 Operation Release 2 Release 3 4 / 24 Validation

Program evolution dynamics Law 5 / 24 Description 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. Organisational stability Over a programÕs lifetime, its rate of development is approximately constant and independent of the resources devoted to system development. Conservation of familiarity Over the lifetime of a system, the incremental change in each release 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.

Software Maintenance: Overview . Software maintenance the activities of changing the system after it has been delivered Types of software maintenance: 6 / 24 Corrective maintenance: repair of software faults Adaptive maintenance: modification of software due to changes in the operating environment (hardware, supporting software) Perfective maintenance: additions to and/or modifications of system functionality due to organizational or business changes

Software Maintenance: .Overview. Distribution of maintenance effort [Fig. 21.3, SE-8] Fault repair (17%) Software adaptation (18%) 7 / 24 Functionality addition or modification (65%)

Software Maintenance: .Overview. 8 / 24 Software maintenance is a natural continuation of the development process (specification, design, implementation, testing). Hence the term evolution (applied especially when the transition from development is seamless) Development and maintenance costs vary from application to application Investing in development leads to reduction of both maintenance costs and overall project costs [slide 9]

Software Maintenance: Overview. Costs of development and maintenance [Fig. 21.4, SE-8] System 1 System 2 0 50 100 Development costs 9 / 24 150 200 250 300 Maintenance costs 350 400 450 500

Software Maintenance: .Overview Why maintenance costs are higher than development costs? Factors: 10 / 24 Team stability: development teams break up after delivery Contractual responsibility: different teams or organizations have the responsibility for maintenance Staff skills: more experienced software engineers tend to avoid maintenance Program age and structure: not structured in the first place, the program copes poorly with changes and its structure degrades

Software Maintenance: Prediction. Maintenance prediction [Fig. 21.5, SE-8] What parts of the system will be the most expensive to maintain? What parts of the system are most likely to be affected by change requests? Predicting maintainability Predicting system changes How many change requests can be expected? 11 / 24 Predicting maintenance costs What will be the lifetime maintenance costs of this system? What will be the costs of maintaining this system over the next year?

Software Maintenance: .Prediction Generally, more complex the software, more expensive its maintenance The relationship between a system and its environment is also important. This relationship is characterized by: Factors used to assess maintainability: 12 / 24 Number and complexity of interfaces Number of inherently volatile requirements The business process in which the system is used Number of requests for corrective maintenance Average time required for impact analysis Average time taken to implement a change Number of outstanding change requests

Evolution Processes. Change requests 13 / 24 The evolution process: overview [Fig. 21.7, SE-8] Impact analysis System release planning Change implementa tion Perfective maintenance Adaptive maintenance Corrective maintenance System release

.Evolution Processes. Change implementation [Fig. 21.8, SE-8] Proposed changes 14 / 24 Requirements analysis Requirements updating Software development

.Evolution Processes Emergency repair [Fig. 21.9, SE-8]. Prompted by: System faults Business changes Environmental changes all requiring urgent treatment Change Analyze requests source code The dangers of emergency repair: 15 / 24 Modify source code Software becomes inconsistent Changes are not reflected in documentation Software ageing is accelerated by workaround solutions Deliver modified system

Legacy Systems: Introduction. Legacy systems: old computer-based systems still in use by organizations 16 / 24 Many of them still business critical Incorporate many changes made over the years Many people have been involved in these changes Replacing legacy systems with new systems is risky, yet keeping them means new changes become more and more expensive

Legacy Systems: .Introduction. Risks of replacing a legacy system: 17 / 24 Specification is difficult because existing documentation is typically incomplete Changing business processes (now adjusted to the system) may entail high costs Undocumented, yet important business rules may be embedded in the system; a new system may break these rules The new system may be delivered late, may cost more than expected, and may not function properly

Legacy Systems: .Introduction Factors that make changes to legacy systems expensive: 18 / 24 In large systems, different parts were implemented by different teams, without consistent programming style It is difficult to find personnel who knows the obsolete programming languages used in old systems In may cases the only documentation is provided by the source code; even this may be missing It is difficult to understand the system given its ad hoc updating over the years Data used by the system is difficult to understand and manipulate; it can also be obsolete and/or redundant

Legacy system assessment . Strategic approaches for dealing with legacy systems: Scrap the system completely When business practices have changed and no longer depend significantly on the system (they may be supported by new COTS) Continue to maintain the system The system works well, is fairly stable, and users do not request many changes Transform the system to improve maintainability When system quality was affected negatively by changes, yet changes are still required Replace the system with a new one When obsolete hardware precludes further operation or the new system can be built at reasonable cost 19 / 24

.Legacy system assessment . Assessing legacy systems example [Fig. 21.13 SE-8] Business value High business value Low quality 9 10 High business value High quality 8 6 7 Low business value High quality Low business value Low quality 2 1 20 / 24 3 4 5 System quality

.Legacy system assessment Assessment of legacy systems includes: (1) Business value assessment Viewpoints: End-users: look at system’s functionality and performance Customers: look at the quality of services provided Business managers: assess the usefulness of the system in terms of business support IT managers: are concerned with the availability of technical support for the system Senior managers: interested in system’s contribution to the business goals 21 / 24 Major criteria: system usage, business processes supported, dependability, system outputs

Legacy system assessment. (2) System quality assessment. Look at all components of the system. Hence: Environment assessment. Support software & hardware platform (maintenance costs, faults, etc. – slide 23) Application software assessment. Factors considered as in slide 24 and quantitative data such as: Number of system change requests Number of different user interfaces Volume of data used by the system 22 / 24

.Legacy system assessment. Factors in environment assessment [Fig. 21.14 SE-8] Factor Supplier stability Failure rate Age Performance Support requirements Maintenance costs Interoperability 23 / 24 Questions Is the supplier is still in existence? Is the supplier financially stable and likely to continue in existence? If the supplier is no longer in business, are the systems maintained by someone else? Does the hardware have a high rate of reported failures? Does the support software crash and force system restarts? How old is the hardware and software? The older the hardware and support software, the more obsolete it will be. It may still function correctly but there could be significant economic and business benefits to moving to more modern systems. Is the performance of the system adequate? Do performance problems have a significant effect on system users? What local support is required by the hardware and software? If there are high costs associated with this support, it may be worth considering system replacement. What are the costs of hardware maintenance and support software licences? Older hardware may have higher maintenance costs than modern systems. Support software may have high annual licensing costs. Are there problems interfacing the system to other systems? Can compilers etc. be used with current versions of the operating system? Is hardware emulation required?

.Legacy system assessment 24 / 24 Factors in application software assessment [Fig. 21.15 SE-8]