We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byCameron Humphres
Modified over 2 years ago
Software Maintenance Main issues: why maintenance is such an issue reverse engineering and its limitations how to organize maintenance
SE, Maintenance, Hans van Vliet, © Relative distribution of software/hardware costs Hardware Development Software Maintenance Year Percent of total cost
SE, Maintenance, Hans van Vliet, © Point to ponder #1 Why does software maintenance cost so much?
SE, Maintenance, Hans van Vliet, © Software Maintenance, definition The process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment
SE, Maintenance, Hans van Vliet, © Maintenance is thus concerned with: correcting errors found after the software has been delivered adapting the software to changing requirements, changing environments,...
SE, Maintenance, Hans van Vliet, © Key to maintenance is in development Higher quality less (corrective) maintenance Anticipating changes less (adaptive and perfective) maintenance Better tuning to user needs less (perfective) maintenance Less code less maintenance
SE, Maintenance, Hans van Vliet, © Kinds of maintenance activities corrective maintenance: correcting errors adaptive maintenance: adapting to changes in the environment (both hardware and software) perfective maintenance: adapting to changing user requirements preventive maintenance: increasing the system’s maintainability
SE, Maintenance, Hans van Vliet, © Distribution of maintenance activities corrective 21% adaptive 25% preventive 4% perfective 50%
SE, Maintenance, Hans van Vliet, © Growth of maintenance problem 1975: ~75,000 people n maintenance (17%) 1990: 800,000 (47%) 2005: 2,500,000 (76%) 2015: ?? (Numbers from Jones (2006))
SE, Maintenance, Hans van Vliet, © Shift in type of maintenance over time Introductory stage: emphasis on user support Growth stage: emphasis on correcting faults Maturity: emphasis on enhancements Decline: emphasis on technology changes
SE, Maintenance, Hans van Vliet, © Major causes of maintenance problems Unstructured code Insufficient domain knowledge Insufficient documentation
SE, Maintenance, Hans van Vliet, © Reverse engineering
SE, Maintenance, Hans van Vliet, © Reverse engineering Does not involve any adaptation of the system Akin to reconstruction of a blueprint Design recovery: result is at higher level of abstraction Redocumentation: result is at same level of abstraction
SE, Maintenance, Hans van Vliet, © Restructuring Functionality does not change From one representation to another, at the same level of abstraction, such as: From spaghetti code to structured code Refactoring after a design step in agile approaches Black box restructuring: add a wrapper With platform change: migration
SE, Maintenance, Hans van Vliet, © Reengineering (renovation) Functionality does change Then reverse engineering step is followed by a forward engineering step in which the changes are made
SE, Maintenance, Hans van Vliet, © Refactoring in case of bad smells Long method Large class Primitive obsession Data clumps Switch statements Lazy class Duplicate code Feature envy Inappropriate intimacy …
SE, Maintenance, Hans van Vliet, © Categories of bad smells Bloaters: something has grown too large Object-oriented abusers: OO not fully exploited Change preventers: hinder further evolution Dispensables: can be removed Encapsulators: deal with data communication Couplers: coupling too high
SE, Maintenance, Hans van Vliet, © Program comprehension Role of programming plans, beacons As-needed strategy vs systematic strategy Use of outside knowledge (domain knowledge, naming conventions, etc.)
SE, Maintenance, Hans van Vliet, © Software maintenance tools Tools to ease perceptual processes (reformatters) Tools to gain insight in static structure Tools to gain insight in dynamic behavior Tools that inspect version history
SE, Maintenance, Hans van Vliet, © Analyzing software evolution data Version-centered analysis: study differences between successive versions History-centered analysis: study evolution from a certain viewpoint (e.g. how often components are changed together)
SE, Maintenance, Hans van Vliet, © Example version-centered analysis
SE, Maintenance, Hans van Vliet, © Example history-centered analysis
SE, Maintenance, Hans van Vliet, © Organization of maintenance W-type: by work type (analysis vs programming) A-type: by application domain L-type: by life-cycle type (development vs maintenance) L-type found most often
SE, Maintenance, Hans van Vliet, © Advantages of L-type departmentalization Clear accountability Development progress not hindered by unexpected maintenance requests Better acceptance test by maintenance department Higher QoS by maintenance department Higher productivity
SE, Maintenance, Hans van Vliet, © Disadvantages of L-type departmentalization Demotivation of maintenance personnel because of status differences Loss of system knowledge during system transfer Coordination costs Increased acceptance costs Duplication of communication channels with users
SE, Maintenance, Hans van Vliet, © Product-service continuum and maintenance
SE, Maintenance, Hans van Vliet, © Service gaps 1.Expected service as perceived by provider differs from service expected by customer 2.Service specification differs from expected service as perceived by provider 3.Service delivery differs from specified services 4.Communication does not match service delivery
SE, Maintenance, Hans van Vliet, © Gap model of service quality
SE, Maintenance, Hans van Vliet, © Maintenance control Configuration control: Identify, classify change requests Analyze change requests Implement changes Fits in with iterative enhancement model of maintenance (first analyze, then change) As opposed to quick-fix model (first patch, then update design and documentation, if time permits)
SE, Maintenance, Hans van Vliet, © Indicators of system decay Frequent failures Overly complex structure Running in emulation mode Very large components Excessive resource requirements Deficient documentation High personnel turnover Different technologies in one system
SE, Maintenance, Hans van Vliet, © SUMMARY most of maintenance is (inevitable) evolution Maintenance problems: Unstructured code Insufficient knowledge about system and domain Insufficient documentation Bad image of maintenance department Lehman’s 3 rd law: a system that is used, will change
© 2005 by Prentice Hall 1 Chapter 1: The Database Environment Modern Database Management 7 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden.
Software Engineering Natallia Kokash 1.
1 Chapter 11 Software Evolution This chapter is extracted from Sommerville’s slides. Text book chapter 21 1.
ABC Technology Project Mrs. Kiddle. ABCs of Technology Word 1 Word 2 Word 3 Word 4 Word 5 Word 6 Word 7 Word 8 Word 9 Word 19 Word 20 Word 21 Word 22.
Januar 2005 S M T O T F L
1 Chapter 1 The Study of Body Function Image PowerPoint Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Copyright © 2008 Cengage Learning Understanding Generalist Practice, 5e, Kirst-Ashman/Hull 1.
1 15 Making the System Operational Lecture Activities of the Implementation and Support Phases Figure 15-1.
25 seconds left….. 24 seconds left….. 23 seconds left…..
PSSA Preparation. Question 1(no calculator) D Question 2 (no calculator)
Chapter 9 – Software Evolution and Maintenance 1Chapter 9 Software evolution.
SOFTWARE MAINTENANCE 1. TOPICS TO BE DISCUSSED.. Definition of Maintenance Software Maintenance Types of Maintenance Maintenance Process Need of Maintenance.
Year 6 mental test 10 second questions Addition and Subtraction Addition.
© 2012 National Heart Foundation of Australia. Slide 2.
©Brooks/Cole, 2001 Chapter 12 Derived Types-- Enumerated, Structure and Union.
Factor P (8-5ab) 2. 4(d² + 4) 3. 3rs(2r – s) 4. 15cd(1 + 2cd) 5. 8(4a² + 3b²) 6. 12xy(3y – 4x) 7. 5x²y(6x + 7y) 8. 3cd²(3c² - 2d) 9. 15bc³(5b +
1 Chapter 10 Fact-finding Techniques Transparencies © Pearson Education Limited 1995, 2005.
McDonald’s calendar 2009 January
Modeling Main issues: What do we want to build How do we write this down.
Document #07-2I RXQ Customer Enrollment Using a Registration Agent (RA) Process Flow Diagram (Move-In) (mod 7/25 & clean-up 8/20) Customer Supplier.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Chapter 27 Software Change.
Jeopardy Topic 1Topic Q 1Q 6Q 11Q 16Q 21 Q 2Q 7Q 12Q 17Q 22 Q 3Q 8Q 13Q 18Q 23 Q 4Q 9Q 14Q 19Q 24 Q 5Q 10Q 15Q 20Q 25 Final Jeopardy.
H to shape fully developed personality to shape fully developed personality for successful application in life for successful.
Model and Relationships 6 M 1 M M M M M M M M M M M M M M M M
Software Maintenance 1 Maurice ter Beek These slides are based on slides for Software Engineering courses by Natallia Kokash, Werner.
FACTORING Think unfoil Work down, Show all steps ax 2 + bx + c.
1 Prof. Valter Bezerra Dantas
Lecture 5: Requirements Engineering Dr Valentina Plekhanova University of Sunderland, UK
Slide 1 Testing Workflow Purpose l Purpose Verify the result from implementation by testing each build Plan the tests in each iteration Integration tests.
We will resume in: 25 Minutes We will resume in: 24 Minutes.
CYPRESS Software Testing By Rick Clements
You have been given a mission and a code. Use the code to complete the mission and you will save the world from obliteration…
Exit a Customer Chapter 8. Exit a Customer 8-2 Objectives Perform exit summary process consisting of the following steps: Review service records Close.
Sets Sets © 2005 Richard A. Medeiros next Patterns.
Component-Based Software Engineering Main issues: assemble systems out of (reusable) components compatibility of components.
1 Lecture 20 Software Maintenance Software Engineering.
McDonalds Kalender Januar
IP Multicast Information management 2 Groep T Leuven – Information department 2/14 Agenda •Why IP Multicast ? •Multicast fundamentals •Intradomain.
Time for a BREAK! You have 45 Minutes. Time Left 44.
Murach's PHP and MySQL, C15© 2010, Mike Murach & Associates, Inc.Slide 1.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 1 Configuration management l Managing the products of system change l Objectives.
Document #07-12G 1 RXQ Customer Enrollment Using a Registration Agent Process Flow Diagram (Switch) Customer Supplier Customer authorizes Enrollment.
DOROTHY Design Of customeR dRiven shOes and multi-siTe factorY Product and Production Configuration Method (PPCM) ICE 2009 IMS Workshops Dorothy Parallel.
C Copyright © 2005, Oracle. All rights reserved. Practice Solutions.
Alter – Information Systems 4th e d. © 2002 Prentice Hall 1 Moving Towards E-Business As Usual.
© 2017 SlidePlayer.com Inc. All rights reserved.