1.1.1 Software Evolution.

Slides:



Advertisements
Similar presentations
Chapter 27 Software Change.
Advertisements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S.
CPSC 875 John D. McGregor Architecture evolution.
PROC-1 3. Software Process. PROC-2 What’s a process? Set of activities in creating software It involves creativity –hard to automate –Requires human judgment.
SOFTWARE MAINTENANCE 24 March 2013 William W. McMillan.
Software Construction and Evolution - CSSE 375 Software Visualization Tools and Software Evolution Shawn and Steve.
CMMI – Continuous as well as staged model CMMI capability levels – Incomplete, performed, managed, defined, quantitatively managed, optimized Example.
1 The Laws of Software Evolution Tori Bowman CSSE 375, Rose-Hulman September 25, 2007 *based on Don Bagert’s lesson.
16/05/2015Dr Andy Brooks1 MSc Software Maintenance MS Viðhald hugbúnaðar Fyrirlestur 39 Lehman´s Laws of Software Evolution Worth a read?
Supported by: Joint MSc curriculum in software engineering European Union TEMPUS Project CD_JEP New Topics for Software Evolution Miloš Radovanović.
1 Software Maintenance and Evolution CSSE 575: Session 9, Part 1 Software Evolution and Visualizing That! Steve Chenoweth Office Phone: (812)
Software Evolution – part 2
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 Course Intro Construction & Evolution CSSE 375 Steve Chenoweth.
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.
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 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Chapter 27 Software Change.
Lecture # 22 Software Evolution
AGILE Methodology. AGILE  derived from the word ‘agile manifesto’, also called the Manifesto for Agile Software Development which is a formal proclamation.
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.
1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 6/e Part 1 Supplementary Slides for Software Engineering: A Practitioner's.
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.
TOPIC R Software Maintenance, Evolution, Program Comprehension, and Reverse Engineering SEG4110 Advanced Software Design and Reengineering.
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.
A Framework for creating hybrid-open source software communities Srinarayan Sharma et. al. Info Systems (2002), 12.
Maintainability of FLOSS Projects
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change.
Analysis of Schema Evolution for Databases in Open-Source Software MSc Thesis - Ioannis Skoulis Department of Computer Science and Engineering.
Module 8: Software Evolution CSEB233 Fundamentals of Software Engineering Badariah Solemon 2010.
©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 1 Chapter 21 Software Evolution.
Manag ing Software Change CIS 376 Bruce R. Maxim UM-Dearborn.
Figures – Chapter 9. Figure 9.1 A spiral model of development and evolution.
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.
Module 8: Software Evolution CSEB233 Fundamentals of Software Engineering Badariah Solemon 2010.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Chapter 9 – Software Evolution 1Chapter 9 Software evolution.
©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.
Part 1 Introduction to Software Engineering 1 copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY.
Software Development Module Code: CST 240 Chapter 6: Software Maintenance Al Khawarizmi International College, AL AIN, U.A.E Lecturer: Karamath Ateeq.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XVI. Software Evolution.
Overview Software Maintenance and Evolution Definitions
Chapter : Introduction to Software Engineering
Chapter : Introduction to Software Engineering
Textbook: SOFTWARE EVOLUTION AND MAINTENANCE, A Practitioner’s Approach, PRIYADARSHI TRIPATHY KSHIRASAGAR NAIK John Wiley & Sons, Inc., 2015.
For University Use Only
Chapter : Introduction to Software Engineering
Chapter : Introduction to Software Engineering
Chapter 9 – Software Evolution and Maintenance
IS301 – Software Engineering V:
Chapter 27 Software Change.
Chapter 9 – Software Evolution
Chapter 9 – Software Evolution
Presentation transcript:

1.1.1 Software Evolution

Although the phrase “software evolution” had been used previously by other researchers, fundamental work in the field of software evolution was done by Lehman and his collaborators. Based on empirical studies [2, 14], Lehman and his collaborators formulated some observations and they introduced them as laws of evolution. The “laws” themselves have “evolved” from three in 1974 to eight by 1997 [15, 16].

The eight laws are briefly explained as follows: 1. Continuing change. Unless a system is continually modified to satisfy emerging needs of users, the system becomes increasingly less useful. 2. Increasing complexity. Unless additional work is done to explicitly reduce the complexity of a system, the system will become increasingly more complex due to maintenance-related changes. 3. Self-regulation. The evolution process is self-regulating in the sense that the measures of products and processes, that are produced during the evolution, follow close to normal distributions.

4. Conservation of organizational stability 4. Conservation of organizational stability. The average effective global activity rate on an evolving system is almost constant throughout the lifetime of the system. In other words, the average amount of additional effort needed to produce a new release is almost the same. 5. Conservation of familiarity. As a system evolves all kinds of personnel, namely, developers and users, for example, must gain a desired level of understanding of the system’s content and behavior to realize satisfactory evolution. A large incremental growth in a release reduces that understanding. Therefore, the average incremental growth in an evolving system remains almost the same.

6. Continuing growth. As time passes, the functional content of a system is continually increased to satisfy user needs. 7. Declining quality. Unless the design of a system is diligently fine-tuned and adapted to new operational environments, the system’s qualities will be perceived as declining over the lifetime of the system.

8. Feedback system. The system’s evolution process involves multi-loop, multi-agent, multi-level feedback among different kinds of activities. Developers must recognize those complex interactions in order to continually evolve an existing system to deliver more functionalities and higher levels of qualities.