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,

  • Published on
    19-Dec-2015

  • View
    215

  • Download
    1

Embed Size (px)

Transcript

  • Slide 1
  • 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 books web-site November 14, 2007
  • Slide 2
  • 2 / 24 Outline n Introduction n Program Evolution Dynamics n Software Maintenance u Overview u Prediction n Evolution Processes n Legacy Systems
  • Slide 3
  • 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.
  • Slide 4
  • 4 / 24.Introduction n A spiral model of development and evolution [Fig. 21.1, SE-8]
  • Slide 5
  • 5 / 24 Program evolution dynamics n
  • Slide 6
  • 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
  • Slide 7
  • 7 / 24 Software Maintenance:.Overview... n Distribution of maintenance effort [Fig. 21.3, SE-8]
  • Slide 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]
  • Slide 9
  • 9 / 24 Software Maintenance: Overview. n Costs of development and maintenance [Fig. 21.4, SE-8]
  • Slide 10
  • 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
  • Slide 11
  • 11 / 24 Software Maintenance: Prediction. n Maintenance prediction [Fig. 21.5, SE-7]
  • Slide 12
  • 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
  • Slide 13
  • 13 / 24 Evolution Processes.. n The evolution process: overview [Fig. 21.7, SE-8]
  • Slide 14
  • 14 / 24.Evolution Processes. n Change implementation [Fig. 21.8, SE-8]
  • Slide 15
  • 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
  • Slide 16
  • 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
  • Slide 17
  • 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
  • Slide 18
  • 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
  • Slide 19
  • 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
  • Slide 20
  • 20 / 24.Legacy system assessment. n Assessing legacy systems example [Fig. 21.13 SE-8]
  • Slide 21
  • 21 / 24..Legacy system assessment n Assessment of legacy systems includes: u Business value assessment (subjective). Viewpoints: End-users: look at systems 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 systems contribution to the business goals u System quality assessment (next)
  • Slide 22
  • 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
  • Slide 23
  • 23 / 24 .Legacy system assessment. n Factors in environment assessment [Fig. 21.14 SE-8]
  • Slide 24
  • 24 / 24 ..Legacy system assessment n Factors in application software assessment [Fig. 21.15 SE-8]

Recommended

View more >