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

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

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

4 / 24.Introduction n A spiral model of development and evolution [Fig. 21.1, SE-8]

5 / 24 Program evolution dynamics n

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

7 / 24 Software Maintenance:.Overview... n Distribution of maintenance effort [Fig. 21.3, SE-8]

8 / 24 Software Maintenance:..Overview.. n 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) n Development and maintenance costs vary from application to application n Investing in development leads to reduction of both maintenance costs and overall project costs [slide 9]

9 / 24 Software Maintenance: …Overview. n Costs of development and maintenance [Fig. 21.4, SE-8]

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

11 / 24 Software Maintenance: Prediction. n Maintenance prediction [Fig. 21.5, SE-7]

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

13 / 24 Evolution Processes.. n The evolution process: overview [Fig. 21.7, SE-8]

14 / 24.Evolution Processes. n Change implementation [Fig. 21.8, SE-8]

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

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

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

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

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

20 / 24.Legacy system assessment…. n Assessing legacy systems example [Fig SE-8]

21 / 24..Legacy system assessment… n Assessment of legacy systems includes: u Business value assessment (subjective). 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 u System quality assessment (next)

22 / 24 …Legacy system assessment.. n System quality assessment. Look at all components of the system. Hence: u Business process assessment. Possible questions:  Are defined process models and procedures in place?  Are processes applied consistently across the company?  What adaptations have been made?  Are relationships with other business processes necessary?  Are processes suitably supported by application software? u Environment assessment: support software & hardware platform (maintenance costs, faults, etc. – slide 23) u 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

23 / 24 ….Legacy system assessment. n Factors in environment assessment [Fig SE-8]

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