 2004 by SEC Chapter 9 Software Maintenance. 2  2004 by SEC 9.1 Software Evolution.

Slides:



Advertisements
Similar presentations
Chapter 27 Software Change.
Advertisements

Chapter 27 Software Change.
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 Configuration Management
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.
Software maintenance Managing the processes of system change.
Chapter 9 – Software Evolution Lecture 1 1Chapter 9 Software evolution.
 2004 by SEC Chapter 9 Software Maintenance. 2  2004 by SEC Chapter 9 Software Maintenance 9.1 Software Evolution 9.2 Types of Software Maintenance.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Chapter 27 Software Change.
Chapter 9 – Software Evolution and Maintenance
Lecture # 22 Software Evolution
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.
©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,
Chapter 3: Software Maintenance Process Omar Meqdadi SE 3860 Lecture 3 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
© S. Demeyer, S. Ducasse, O. Nierstrasz Intro.1 1. Introduction Goals Why Reengineering ?  Lehman's Laws  Object-Oriented Legacy Typical Problems  common.
©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 14: Maintenance Effort Models Omar Meqdadi SE 3860 Lecture 14 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
SOFTWARE MAINTENANCE 1. TOPICS TO BE DISCUSSED.. Definition of Maintenance Software Maintenance Types of Maintenance Maintenance Process Need of Maintenance.
©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.
Lecture 14 Maintaining the System and Managing Software Change SFDV Principles of Information Systems.
©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 Chapter 9 Software Evolution1.
HNDIT23082 Lecture 06:Software Maintenance. Reasons for changes Errors in the existing system Changes in requirements Technological advances Legislation.
Chapter 9 – Software Evolution 1Chapter 9 Software evolution.
Chapter 9 – Software Evolution 1Chapter 9 Software evolution.
Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
©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.
1 / 14 CS 425/625 Software Engineering Software Change Based on Chapter 27 of the textbook [SE-6] Ian Sommerville, Software Engineering, 6 th Ed., Addison-Wesley,
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.
Software Configuration Management
Overview Software Maintenance and Evolution Definitions
Chapter 9 – Software Evolution
Chapter 18 Maintaining Information Systems
Introduction to Software Evolution and Maintenance
Managing the System PPT SOURCE : Shari L. Pfleeger Joann M. Atlee.
G. Pullaiah College of Engineering and Technology, Kurnool
Software Engineering (CSI 321)
CS 425/625 Software Engineering 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.
Lecture 06:Software Maintenance
Chapter 9 – Software Evolution
Chapter 9 – Software Evolution
Presentation transcript:

 2004 by SEC Chapter 9 Software Maintenance

2  2004 by SEC 9.1 Software Evolution

3  2004 by SEC Software Evolution l It is impossible to produce system of any size which do not need to be changed. Once software is put into use, new requirements emerge and existing requirements changes as the business running that software changes. l Parts of the software may have to be modified to correct errors that are found in operation, improve its performance or other non-functional characteristics. l All of this means that, after delivery, software systems always evolve in response to demand for change.

4  2004 by SEC Program Evolution Dynamic LawDescription Continuing changeA program that is used in real-world environment necessarily must change or 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 simplify the structure. l Program evolution dynamic is the study of system change. The majority of work in this area has been carried out by Lehman and Belady. From these studies, they proposed a sets of laws concerning system change.

5  2004 by SEC Program Evolution Dynamic (cont’d) LawDescription Large program evolutionProgram evolution is self-regulation process. System attributes such as size, time between release and the number of report errors are 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 the system development Conservation of familiarityOver the lifetime of system, the incremental change in each release is approximately constant.

6  2004 by SEC Software Evolution Approaches l There are a number of different strategies for software change.[SOM2004].[SOM2004] –Software maintenance –Architectural transformation –Software re-engineering. l Software maintenance –Changes to the software are made in response to changed requirements but the fundamental structure of the software remains stable. This is most common approach used to system change.

7  2004 by SEC 9.2 Types of Software Maintenance

8  2004 by SEC Software Maintenance l Software maintenance is the general process of changing a system after it has been diverted. l The change may be simple changes to correct coding errors, more extensive changes to correct design errors or significant enhancement to correct specification error or accommodate new requirements.

9  2004 by SEC Maintenance Characteristics l We need to look at maintenance from three different viewpoints: [PRE2004][PRE2004] –the activities required to accomplish the maintenance phase and the impact of a software engineering approach (or lack thereof) on the usefulness of such activities –the costs associated with the maintenance phase –the problems that are frequently encountered when software maintenance is undertaken

10  2004 by SEC l Maintenance to repair software faults –Changing a system to correct deficiencies in the way meets its requirements l Maintenance to adapt software to a different operating environment –Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation l Maintenance to add to or modify the system’s functionality –Modifying the system to satisfy new requirements Types of Maintenance

11  2004 by SEC Maintenance effort distribution.[SOM2004].[SOM2004]

12  2004 by SEC Development vs. Maintenance not directly linked to the real world directly driven by the real world freedomconstrained by existing system defects have no immediate effect defects disrupt production methods availablesystem not using current methods standards may be enforcedshifting standards, if any

13  2004 by SEC Maintenance Examples l Y2K –many, many systems had to be updated –language analyzers (find where changes need to be made) l Anti-Virus Software –don't usually have to update software, but must send virus definitions

14  2004 by SEC Maintenance Examples (cont’d) l Operating System Patching –Microsoft, Apple, Linux/Unix –OS is core to use of computer, so it must be constantly maintained l Commercial Software in General –customers need to be informed of updates –updates have to be easily available - web is good tool

15  2004 by SEC The Maintenance Process l Maintenance process vary considerably depending on the types of software being maintained, the development processes used in an organization and people involved in the process. Change requests Impact analysis Release planning Change implementation System release Fault repair Flat form adaptation System enhancement Overview of the Maintenance Process.[SOM2004].[SOM2004]

16  2004 by SEC Why is Maintenance Inefficient? l Factors adversely effect maintenance –Lack of models or ignorance of available models (73%) –Lack of documentation (67.6%) –Lack of time to update existing documentation (54.1%) l Other factors (1994 study) –Quality of original application –Documentation quality –Rotation of maintenance people

17  2004 by SEC Why is Maintenance Inefficient? (cont’d) l More factors (Yip ’95 study) –Lack of human resources –Different programming styles conflict –Lack of documentation and tools –Bad maintenance management –Documentation policy –Turnover

18  2004 by SEC 9.3 Maintenance Techniques

19  2004 by SEC Architectural Evolution l There is a need to convert many legacy systems from a centralised architecture to a client-server architecture l Change drivers –Hardware costs. Servers are cheaper than mainframes –User interface expectations. Users expect graphical user interfaces –Distributed access to systems. Users wish to access the system from different, geographically separated, computers

20  2004 by SEC User Interface Distribution l UI distribution takes advantage of the local processing power on PCs to implement a graphical user interface l Where there is a clear separation between the UI and the application then the legacy system can be modified to distribute the UI l Otherwise, screen management middleware can translate text interfaces to graphical interfaces

21  2004 by SEC User Interface Distribution [SOM2004][SOM2004]

22  2004 by SEC 9.4 The Management of Maintenance

23  2004 by SEC Model of Maintenance Effort Model of maintenance effort M = p + K^(c-d) [PRE2004][PRE2004] l M = total maintenance effort over entire lifecycle l p = productive efforts: analysis, design, code, test l c = complexity due to lack of structured design and documentation l d = degree of familiarization with the system l K = empirically determined constant

24  2004 by SEC Model of Maintenance Effort (cont’d) Model of maintenance effort M = p + K^(c-d) l Cost of maintenance increases exponentially. l Costs are reduced by structured development l Costs are reduced by giving the maintenance team time to become thoroughly familiar with the system

25  2004 by SEC What Affects the Maintainability of an Application? l Application age –(software rust?) older programs were probably worse written and have probably been patched more l Size –measured in KLOC, number of input/output files l Programming language –4gls are supposed to produce more maintainable code than 3gls

26  2004 by SEC What Affects the Maintainability of an Application? (cont’d) l Processing environment –files harder to maintain than databases, real-time harder than batch l Analysis and design methodologies –well designed software is supposed to be much easier to maintain l Structured programming –there is conflicting evidence whether this really helps

27  2004 by SEC What Affects the Maintainability of an Application? (cont’d) l Modularization –(central thesis of all the oo techniques) small reasonably self contained pieces of code should be easier to maintain l Documentation generation –maintenance of documentation is as expensive as maintenance of code l End-user involvement –some researchers believe when end users are more involved maintenance decreases

28  2004 by SEC What Affects the Maintainability of an Application? (cont’d) l Maintenance management –scheduling and the attitudes of management to affects productivity

29  2004 by SEC Problems in Managing Maintenance l Changing priorities –chaotic nature of maintenance requests, the length of maintenance tasks causing new requests to come along before an ongoing task is done. l Inadequate testing methods –lack of time set aside for testing, of comprehensive test data, of rigorous testing requirements as a standard for signing off. l Performance measurement difficulties –how do you measure individual or group performance? l System documentation incomplete or non-existent –training takes a long time for learning an application so programmers get stuck on one piece of software. l Adapting to the rapidly changing business environment –hardware and software also become obsolete.

30  2004 by SEC Maintenance Prediction l Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs –Change acceptance depends on the maintainability of the components affected by the change –Implementing changes degrades the system and reduces its maintainability –Maintenance costs depend on the number of changes and costs of change depend on maintainability

31  2004 by SEC Maintenance Prediction (cont’d) l Predicting the number of changes requires and understanding of the relationships between a system and its environment l Tightly coupled systems require changes whenever the environment is changed l Factors influencing this relationship are –Number and complexity of system interfaces –Number of inherently volatile system requirements –The business processes where the system is used

32  2004 by SEC Maintenance Prediction (cont’d) l Predictions of maintainability can be made by assessing the complexity of system components l Studies have shown that most maintenance effort is spent on a relatively small number of system components l Complexity depends on –Complexity of control structures –Complexity of data structures –Procedure and module size

33  2004 by SEC Maintenance Prediction (cont’d) l Process measurements may be used to assess maintainability –Number of requests for corrective maintenance –Average time required for impact analysis –Average time taken to implement a change request –Number of outstanding change requests l If any or all of these is increasing, this may indicate a decline in maintainability

34  2004 by SEC Development/Maintenance Costs [SOM2004][SOM2004]

35  2004 by SEC l Team stability –Maintenance costs are reduced if the same staff are involved with them for some time l Contractual responsibility –The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change l Staff skills –Maintenance staff are often inexperienced and have limited domain knowledge l Program age and structure –As programs age, their structure is degraded and they become harder to understand and change Maintenance Cost Factors

36  2004 by SEC References l [PRE2004] Roger S. Pressman. Software Engineering: a practitioner’s approach, 6th edition. McGRAW-HILL, l [SOM2004] Ian Sommerville. Software Engineering, 7th edition. Addison Wesley, 2004