Software maintenance Managing the processes of system change.

Slides:



Advertisements
Similar presentations
Chapter 27 Software Change.
Advertisements

Chapter 27 Software Change.
Chapter 11 Software Evolution
Chapter 2 – Software Processes
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.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Software evolution.
Software evolution.
 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.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Software Re-engineering
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.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Chapter 9 – Software Evolution 1Chapter 9 Software evolution CS 425 November 12, 2013 Ian Sommerville, Software Engineering, 9 th Edition Pearson Education,
Software Engineering CS3003 Lecture 3 Software maintenance and evolution.
Chapter 3: Software Maintenance Process Omar Meqdadi SE 3860 Lecture 3 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change.
©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 1 Chapter 21 Software Evolution.
Manag ing Software Change CIS 376 Bruce R. Maxim UM-Dearborn.
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28Slide 1 CO7206 System Reengineering 4.2 Software Reengineering Most slides are Slides.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 1 Legacy Systems l Older software.
Software Maintenance Speaker: Jerry Gao Ph.D. San Jose State University URL: Sept., 2001.
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 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.
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.
© SERG Reverse Engineering (Software Maintenance & Reengineering) Software Maintenance Managing the processes of system change.
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,
Chapter 25 – Configuration Management 1Chapter 25 Configuration management.
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
Chapter 9 – Software Evolution
Software Engineering (CSI 321)
CS 425/625 Software Engineering Software Evolution
Software Testing and Maintenance Maintenance and Evolution Overview
Legacy Systems Older software systems that remain vital to an organisation.
Chapter 9 – Software Evolution and Maintenance
IS301 – Software Engineering V:
Software Re-Engineering
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:

Software maintenance Managing the processes of system change

Topics covered The maintenance process System documentation Program evolution dynamics Maintenance costs Maintainability measurement

Software maintenance Modifying a program after it has been put into use Maintenance management is concerned with planning and predicting the process of change Configuration management is the management of products undergoing change. Covered in the following chapter

Maintenance is inevitable The system requirements are likely to change while the system is being developed because the environment is changing. Therefore a delivered system won't meet its requirements! Systems are tightly coupled with their environment. When a system is installed in an environment it changes that environment and therefore changes the system requirements. Systems MUST be maintained therefore if they are to remain useful in an environment

Types of maintenance Perfective maintenance Adaptive maintenance Changing a system to make it meet its requirements more effectively Adaptive maintenance Changing a system to meet new requirements Corrective maintenance Changing a system to correct deficiencies in the way meets its requirements Preventive Maintenance

Distribution of maintenance effort

Evolving systems It is usually more expensive to add functionality after a system has been developed rather than design this into the system Maintenance staff are often inexperienced and unfamiliar with the application domain Programs may be poorly structured and hard to understand Changes may introduce new faults as the complexity of the system makes impact assessment difficult The structure may be degraded due to continual change There may be no documentation available to describe the program

Maintenance management Maintenance has a poor image amongst development staff as it is not seen as challenging and creative Maintenance costs increase as the software is maintained The amount of software which has to be maintained increases with time Inadequate configuration management often means that the different representations of a system are out of step

The maintenance process Maintenance is triggered by change requests from customers or marketing requirements Changes are normally batched and implemented in a new release of the system Programs sometimes need to be repaired without a complete process iteration but this is dangerous as it leads to documentation and programs getting out of step

The maintenance process

Change processes Fault repair process Iterative development process

System documentation Requirements document System architecture description Program design documentation Source code listings Test plans and validation reports System maintenance guide

Document production Structure documents with overviews leading the reader into more detailed technical descriptions Produce good quality, readable manuals - they may have to last 20 years Use tool-generated documentation whenever possible

Maintenance costs Usually greater than development costs (2* to 100* depending on the application) Affected by both technical and non-technical factors Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult. Ageing software can have high support costs (e.g. old languages, compilers etc.)

Development/maintenance costs

Maintenance cost factors Module independence It should be possible to change one module without affecting others Programming language High-level language programs are easier to maintain Programming style Well-structured programs are easier to maintain Program validation and testing Well-validated programs tend to require fewer changes due to corrective maintenance

Maintenance cost factors Documentation Good documentation makes programs easier to understand Configuration management Good CM means that links between programs and their documentation are maintained Application domain Maintenance is easier in mature and well-understood application domains Staff stability Maintenance costs are reduced if the same staff are involved with them for some time

Maintenance cost factors Program age The older the program, the more expensive it is to maintain (usually) External environment If a program is dependent on its external environment, it may have to be changed to reflect environmental changes Hardware stability Programs designed for stable hardware will not require to change as the hardware changes

Maintenance metrics Control complexity Can be measured by examining the conditional statements in the program Data complexity Complexity of data structures and component interfaces. Length of identifier names Longer names imply readability Program comments Perhaps more comments mean easier maintenance

Maintenance metrics Coupling How much use is made of other components or data structures Degree of user interaction The more user I/O, the more likely the component is to require change Speed and space requirements Require tricky programming, harder to maintain

Process metrics 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 If any or all of these is increasing, this may indicate a decline in maintainability

Key points Three types of maintenance are perfective, adaptive and corrective Maintenance costs usually exceed development costs for large, long-lifetime systems Investing effort in maintainability is therefore likely to be cost-effective in the long-term Documentation should include requirements, design and validation documents