Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1

© 2010 John Wiley & Sons Ltd. Chapter 29: Software Maintenance 2

Learning Goals of This Chapter What are the units of software maintenance? What are the differences between corrective, adaptive, perfective, and preventative maintenance? What are some management challenges in maintenance? Process challenges? What are the main technical issues? What is the maintenance process? How do patches work? What standards are there for software maintenance? What is reverse engineering? Reengineering? What maintenance metrics are available? Requirements analysis Design Implementation Testing Maintenance Planning The Software Development Lifecycle 3

© 2010 John Wiley & Sons Ltd. Types of Maintenance Repair – Fixing defects (relative to existing requirements) Enhancement – New requirements – Change design or implementation (no functional change) 4

© 2010 John Wiley & Sons Ltd. Types of Maintenance Lientz & Swanson Corrective – defect identification and removal Adaptive – changes resulting from operating system, hardware or DBMS changes Perfective – changes resulting from user requests Preventive – changes made to the software to make it more maintainable Repair Enhance 5

Example of Corrective Maintenance Request Maintenance Request 78 Problem: When the player changes the value of a quality, the computations are specified to keep the total invariant, but they do not. Example: If the qualities are strength = 10, patience = 0.8 and endurance = 0.8 (sum = 11.6), and the player adjusts strength to 11, the result is strength = 11, patience = 0 and endurance = 0. These do not sum to © 2010 John Wiley & Sons Ltd. 6

Example of Perfective Maintenance Request Maintenance Request 162 Modify Encounter so that the game begins with areas and connections a coordinated style. When the player achieves level 2 status, all areas and connections are displayed in an enhanced coordinated style, which is special to level 2. The art department will provide the required images. © 2010 John Wiley & Sons Ltd. 7

Example of an Estimate for Implementing a Maintenance Request Activity Estimate (person- days) Activity Estimate (person- days) 1. Understand the problem and identify the functions that must be modified or added. 2 – 5 6. Compile and integrate into baseline Design the changes1 – 4 7. Test functionality of changes Perform impact analysis1 – 4 8. Perform regression testing Implement changes in source code1 – 4 9. Release new baseline and report results 1 5. Change SRS, SDD, STP, configuration status 2 – 6TOTAL © 2010 John Wiley & Sons Ltd. 8

A Typical Maintenance Flow Proposed M. R.’s Approved M. R.’s Modified source & documentation Current source & documentation Change control board Maintenance engineer Written MR’s Maintenance manager Marketing Rejected MR’s Customer Help desk nominal path Graphics reproduced with permission from Corel. © 2010 John Wiley & Sons Ltd. 9

Maintenance : Impact of Defect MR Requirements Defect injected here Architecture System code Interface specs Detailed design Function code Module (e.g., package) code Requirements Architecture System code Interface specs Detailed design Function code: Defect injected here Module (e.g., package) code Maximal impactMinimal impact Key: Impact to shaded phases © 2010 John Wiley & Sons Ltd. 10

Impact of MR #162 Requirements Architecture System code Interface specs Detailed design Function code Module (e.g., package) code Add: “change appearance when player achieves new levels” Accommodate ability to change global appearance: use Abstract Factory design pattern Add interface methods for Layout package Add classes and methods as per detailed design Modify gameplay control code © 2010 John Wiley & Sons Ltd. 11

Help desk 1. Interface with customer ComplaintsMarketing Patch (optional) Execute with patch Docu- ment patch … Maintenance and Patching © 2010 John Wiley & Sons Ltd. 12

Maintenance & Patching 1. Get maintenance request 2. Approve changes Create patch 3. Plan changes Assess impact 4. Change code and documentation Coordinate Test changesImplement Update documentation Remove patch Docu- ment patch optional Execute with patch Release Document patch removal © 2010 John Wiley & Sons Ltd. 13

disadvantages May be a complete solution to the problem Keeps customers satisfied Enables continued operation and testing without presence of the defect Avoids masking other defects Enables test of fix May duplicate work – patch and final fix both implemented Temporaries sometimes never replaced – proper fix deferred forever Complicates final fix (where applicable) – must remove Complicates documentation process When tools used for insertion -- may compromise code base. advantages Maintenance Patches © 2010 John Wiley & Sons Ltd. 14

Software Trouble Reports, Maintenance Requests and Correction Reports Software Trouble Report STR Software Trouble Report STR Software Trouble Report STR Software Trouble Report STR Software Trouble Report STR Maintenance Request 1293 Correction Report Maintenance Request Correction Report Maintenance Request Correction Report Maintenance Request © 2010 John Wiley & Sons Ltd. 15

1. Problem identification 1.1 Input 1.2 Process 1.3 Control 1.4 Output 1.5 Quality factors 1.6 Metrics 2. Analysis 2.1 Input 2.2 Process Feasibility analysis Detailed analysis Control, Output, Quality factors, Metrics. 3. Design Input, Process, Control, Output, Quality factors, Metrics. IEEE “Software Maintenance” Table of Contents © 2010 John Wiley & Sons Ltd. 16

1 Problem identification 1.1 Input 1.2 Process 1.3 Control 1.4 Output 1.5 Quality factors 1.6 Metrics 4.2 Analysis 2.1 Input 2.2 Process Feasibility analysis Detailed analysis Control, Output, Quality factors, Metrics. 4.3 Design Input, Process, Control, Output, Quality factors, Metrics. 4 Implementation 4.1 Input 4.2 Process Coding and & testing Risk analysis & review Test-readiness review Control, Output, Quality factors, Metrics. 5 System test Input, Process, Control, Output, Quality factors, Metrics. 6. Acceptance test Input, Process, Control, Output, Quality factors, Metrics. 7 Delivery Input, Process, Control, Output, Quality factors, Metrics. IEEE “Software Maintenance” © 2010 John Wiley & Sons Ltd. 17

© 2010 John Wiley & Sons Ltd. Six Attributes of Each Maintenance Request Phase (IEEE) 1. Problem identification 2. Analysis 3. Design 4. Implementation 5. System test 6. Acceptance test 7. Delivery PhaseAttributes a. Input life cycle arti- facts for this step b. Process required for this step c. How the process is controlled d. Output life cycle artifacts e. Process quality factors involved f. Metrics for this step 18

Using Linear Regression 300 Number of detailed requirements Number of person-months detailed requirements completed with 6 person months © 2010 John Wiley & Sons Ltd. 19

EncounterEnvironment Package (Before Modification) GameEnvironment GameCharacter GameArea EncounterEnvironment Area EncounterEnvironment GameAreaConnection EncounterAreaConnection © 2010 John Wiley & Sons Ltd. 20

Abstract Factory Applied to Encounter Area Level3Area Level3Factory getArea() getAreaConnection() EnvironmentFactory getArea() buildConnection() EncounterEnvironment Client 1..n... © 2010 John Wiley & Sons Ltd. 21

Abstract Factory Applied to Encounter Area Level2AreaLevel1AreaLevel3Area Level1Factory getArea() getAreaConnection() Level2Factory getArea() getAreaConnection() Level3Factory getArea() getAreaConnection() EncounterAreaConnection EnvironmentFactor y getArea() getConnection() EncounterEnvironment Level1AreaConnectionLevel2AreaConnection Client Level3AreaConnection «create» 1..n © 2010 John Wiley & Sons Ltd. 22

Migration Plan for Level-based Graphics © 2010 John Wiley & Sons Ltd. 23

Migration Plan for Level-based Graphics © 2010 John Wiley & Sons Ltd. 24

Original Video Store Architecture DVDRentals DVDAccess «facade» DVDRental DVDCustomerAccess «facade» … … DVDs VSCustomers © 2010 John Wiley & Sons Ltd. 25

Reengineered Video Store Architecture DVDRentals DVDAccess «facade» DVDRentalAccess «facade» VSCustomerAccess «facade» DVDs VSCustomers videoStore «to be completed» nonVideoItems NonVideoAccess «facade» XX Key: reengineered parts: © 2010 John Wiley & Sons Ltd. 26

Accounts received Size (lower value = lower maintenance effort) Percentage of comment lines (higher value = lower maintenance effort) Sick day recorder TimesheetModule: LOWEST EFFORT HIGHEST EFFORT Predicting Relative Maintenance Effort © 2010 John Wiley & Sons Ltd. 27

Measuring Maintenance Productivity © 2010 John Wiley & Sons Ltd.

Assessing Maintenance Operations January February March April May June July August “Fixing” MR’s Enhancement MR’s # weeks open 5 10 E.g., in April, the average enhancement MR had been open for 8 weeks. © 2010 John Wiley & Sons Ltd.