Figures – Chapter 9. Figure 9.1 A spiral model of development and evolution.

Slides:



Advertisements
Similar presentations
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Software Evolution IS301 – Software.
Advertisements

Chapter 11 Software Evolution
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,
Software Evolution – part 2
Software Evolution Managing the processes of software system change
Dr Kettani, Spring 2002 Software Engineering IIFrom Sommerville, 6th edition Software change l Managing the processes of software system change.
SWE Introduction to Software Engineering
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
1 Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Software evolution.
Software evolution.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Software maintenance Managing the processes of system change.
 2004 by SEC Chapter 9 Software Maintenance. 2  2004 by SEC 9.1 Software Evolution.
Chapter 9 – Software Evolution Lecture 1 1Chapter 9 Software evolution.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Chapter 27 Software Change.
Chapter 9 – Software Evolution and Maintenance
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
CPSC 871 John D. McGregor MMS1 Maintenance & a new trend.
Software evolution. Objectives l To explain why change is inevitable if software systems are to remain useful l To discuss software maintenance and maintenance.
Software change  Managing the processes of software system change.
Chapter 1 Software and Software Engineering. A Quick Quiz 1. What percentage of large projects have excess schedule pressure? 25% 50% 75% 100% 2. What.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change.
Software Engineering Lecture 20 Software Maintenance.
Chapter 9 – Software Evolution 1Chapter 9 Software evolution CS 425 November 12, 2013 Ian Sommerville, Software Engineering, 9 th Edition Pearson Education,
Software – Acquisition & Testing. ICT5 How to acquire software There are several options: The software may be written by the end-user; A specialist department.
Chapter 9 Software Evolution.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change.
 CS 5380 Software Engineering Chapter 9 Software Evolution.
Chapter 11 Maintaining the System System evolution Legacy systems Software rejuvenation.
Manag ing Software Change CIS 376 Bruce R. Maxim UM-Dearborn.
Lecture 1 Chapter 9 Software evolution1. Topics covered Evolution processes Change processes for software systems Program evolution dynamics Understanding.
SWE311_Ch01 (071) Software & Software Engineering Slide 1 Chapter 1 Software and Software Engineering Chapter 1 Software and Software Engineering.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution 1.
Software Evolution Program evolution dynamics Software maintenance Complexity and Process metrics Evolution processes 1.
Software Maintenance Speaker: Jerry Gao Ph.D. San Jose State University URL: Sept., 2001.
Chapter 9 – Software Evolution 1Chapter 9 Software evolution.
Chapter 9 – Software Evolution 1Chapter 9 Software evolution.
Chapter 9 – Software Evolution Lecture 1 Chapter 9 Software evolution1.
Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
1 Software Maintenance The process of changing the system after it has been delivered and in operation Software change is inevitable –New requirements.
Chapter 9 – Software Evolution Chapter 9 Software Evolution130/10/2014.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Chapter 9 – Software Evolution 1Chapter 9 Software evolution.
CS223: Software Engineering Lecture 2: Introduction to Software Engineering.
Chapter 9 – Software Evolution 1Chapter 9 Software evolution CS 425 November 12, 2012 Ian Sommerville, Software Engineering, 9 th Edition Pearson Education,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Software change Software change is inevitable –New requirements emerge when the software is used –The business environment changes –Errors must be repaired.
CS223: Software Engineering Lecture 32: Software Maintenance.
© SERG Reverse Engineering (Software Maintenance & Reengineering) Software Maintenance Managing the processes of system change.
Software Development Module Code: CST 240 Chapter 6: Software Maintenance Al Khawarizmi International College, AL AIN, U.A.E Lecturer: Karamath Ateeq.
Overview Software Maintenance and Evolution Definitions
Chapter 9 – Software Evolution
Environment Assessment
Chapter 9 – Software Evolution
Chapter 9 – Software Evolution
CS 425/625 Software Engineering Software Evolution
1.1.1 Software Evolution.
Chapter 9 – Software Evolution and Maintenance
Chapter 9 Software Maintenance
IS301 – Software Engineering V:
Chapter 27 Software Change.
Chapter 9 – Software Evolution
Chapter 8 Software Evolution.
Chapter 9 – Software Evolution
Chapter 9 – Software Evolution
Presentation transcript:

Figures – Chapter 9

Figure 9.1 A spiral model of development and evolution

Figure 9.2 Evolution and servicing

Figure 9.3 Change identification and evolution processes

Figure 9.4 The software evolution process

Figure 9.5 Change implementation

Figure 9.6 The emergency repair process

Figure 9.7 Lehman’s laws LawDescription Continuing changeA program that is used in a real-world environment must necessarily change, or else become progressively less useful in that environment. Increasing complexityAs 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 stabilityOver 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 growthThe functionality offered by systems has to continually increase to maintain user satisfaction. Declining qualityThe quality of systems will decline unless they are modified to reflect changes in their operational environment. Feedback systemEvolution processes incorporate multiagent, multiloop feedback systems and you have to treat them as feedback systems to achieve significant product improvement.

Figure 9.8 Maintenance effort distribution

Figure 9.9 Development and maintenance costs

Figure 9.10 Maintenance prediction

Figure 9.11 The reengineering process

Figure 9.12 Reengineering approaches

Figure 9.13 An example of a legacy system assessment

Figure 9.14 Factors used in environment assessment FactorQuestions Supplier stabilityIs the supplier still in existence? Is the supplier financially stable and likely to continue in existence? If the supplier is no longer in business, does someone else maintain the systems? Failure rateDoes the hardware have a high rate of reported failures? Does the support software crash and force system restarts? AgeHow 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 a more modern system. PerformanceIs the performance of the system adequate? Do performance problems have a significant effect on system users? Support requirements 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. Maintenance costsWhat 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. InteroperabilityAre there problems interfacing the system to other systems? Can compilers, for example, be used with current versions of the operating system? Is hardware emulation required?

Figure 9.15 Factors used in application assessment FactorQuestions UnderstandabilityHow difficult is it to understand the source code of the current system? How complex are the control structures that are used? Do variables have meaningful names that reflect their function? DocumentationWhat system documentation is available? Is the documentation complete, consistent, and current? DataIs there an explicit data model for the system? To what extent is data duplicated across files? Is the data used by the system up to date and consistent? PerformanceIs the performance of the application adequate? Do performance problems have a significant effect on system users? Programming languageAre modern compilers available for the programming language used to develop the system? Is the programming language still used for new system development? Configuration management Are all versions of all parts of the system managed by a configuration management system? Is there an explicit description of the versions of components that are used in the current system? Test dataDoes test data for the system exist? Is there a record of regression tests carried out when new features have been added to the system? Personnel skillsAre there people available who have the skills to maintain the application? Are there people available who have experience with the system?