1 / 58

10. MAINTENANCE

10. MAINTENANCE . Software Engineering Roadmap: Chapter 10 Focus. Identify corporate practices. Keep application useful after delivery - Fix defects - Enhance the application. Plan project. Maintain. Analyze requirements. Integrate & test system. Design. Implement.

paul2
Download Presentation

10. MAINTENANCE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 10. MAINTENANCE

  2. Software Engineering Roadmap: Chapter 10 Focus Identify corporate practices Keep application useful after delivery - Fix defects - Enhance the application Plan project Maintain Analyze requirements Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  3. Development Learning Goals of This Chapter $ • Understand how “Software Maintenance” is defined • Appreciate the cost of maintenance • Understand software maintenance issues • Organize for maintenance • Use IEEE maintenance standard • Apply maintenance metrics Maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  4. 1. Introduction

  5. Service a Maintenance Request 1 One way to ... 1. Be prepared to keep required metrics. Include.. • … lines of code added • … lines of code changed • … time taken: 1. preparation 2. design 3. code 4. test 2. Ensure that the request has been approved 3. Understand the problem thoroughly • reproduce the problem • otherwise get clarification 4. Classify the MR as repair or enhancement 5. Decide whether the implementation requires a redesign at a higher level • if so, consider batching with other MR’s 6. Design the required modification (i.e., incorporate the change) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  6. Service a Maintenance Request 2 One way to ... 7. Plan transition from current design 8. Assess change’s impact throughout the application • small changes can have major impact! 9. Implement the changes 10. Perform unit testing on the changed parts 11. Perform regression testing • ensure changes haven’t compromised existing capabilities 12. Perform system testing with new capabilities 13. Update the configuration, requirement, design and test documentation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  7. Software Maintenance Issues • Management • Return on investment hard to define • Process • Extensive coordination required to handle stream of Maintenance Requests • Technical • Covering full impact of changes • Testing very expensive compared with the utility of each change • focused tests ideal but expensive • regression testing still required Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  8. 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 2 - 3 2. Design the changes 1 - 4 7. Test functionality of changes 2 - 4 3. Perform impact analysis 1 - 4 8. Perform regression testing 2 - 4 4. Implement changes in source code 1 - 4 9. Release new baseline and report results 1 5. Change SRS, SDD, STP, configuration status 2 - 6 TOTAL 14 - 35 Estimating the Cost of Servicing a Maintenance Request Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  9. RoadMap to Establish Maintenance(After Pigoski) 1a. Design for maintainability-- section 6.3 1b. Ensure supportability 1c. Plan for transition to maintenance 1d. Plan post-delivery logistics • 2. Determine main-tenance scope • all types? • corrective only? • limited corrective? • -- section 2 • 4. Develop maintenance plan • Change control approval procedure • Help desk • etc. • -- section 5 • 3. Identify maintainers • in-house? • contracted? 6. Perform maintenance -- section 3 5. Estimate costs -- table 10.1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  10. 2. Types of software maintenance

  11. Types of MaintenanceLientz & Swanson • Corrective • defect identification and removal • Adaptive • changes resulting from operating system, hardware or DBMS changes • Perfective • changes resulting from user requests • Preventative • changes made to the software to make it more maintainable Fixing Enhancing

  12. Example of Corrective Maintenance Request Maintenance Request 78 The computations that ensue when the player changes the value of a quality, are supposed to keep the total invariant, but they do not. For example, if the qualities are strength = 10, patience = 0.8 and endurance = 0.8 (sum = 11.6), and the player adjusts strength to 11, then the result is strength = 11, patience = 0 and endurance = 0, which do not sum to 11.6. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  13. Example of Perfective Maintenance Request Maintenance Request 162 Modify Encounter so that the game begins with areas and connections a coordinated style.

  14. Example of Perfective Maintenance Request Maintenance Request 162 Modify Encounter so that the game begins with areas and connections in 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 etc. The art department will provide the required images. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  15. 3. Maintenance techniques

  16. Impact of MR #162 Add: “change appearance when player achieves new levels” Requirements Accommodate ability to change global appearance: use Abstract Factory design pattern Architecture

  17. Impact of MR #162 Add: “change appearance when player achieves new levels” Requirements Accommodate ability to change global appearance: use Abstract Factory design pattern Architecture Detailed design Interface specs Add interface methods for Layout package Function code Add classes and methods as per detailed design Module (e.g., package) code Modify gameplay control code System code Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  18. Maintenance With and Without Reengineering

  19. Maintenance With and Without Reengineering Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  20. Re-engineering Management Training; Re-engineering Encounter to Conform Current Encounter Software re- engineering Play management version of Encounter

  21. Re-engineering Encounter to Conform to Management Training Current Encounter Business process Re-engineering Specify follow-up courses Write training objectives Take introductory mgmt. courses Senior Management Take intermediate mgmt. courses Evaluate results Middle Management Management simulation adaptation of Encounter New Management Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  22. Options for Dealing with Legacy Systems • Continue to maintain • Discontinue maintenance and -- 1. Replace • buy replacement • OR build replacement • reverse engineer legacy system • or develop new architecture • possibly replace in phases 2. Incorporate as integral part of new application • freeze maintenance 3. Encapsulate and use as server • consider using Adapter design pattern OR OR Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  23. Legacy Architectures Incorporation Encapsulation New system Extensions Legacy Application Modifications (fig i)0

  24. Legacy Architectures uses... Incorporation Encapsulation New system (fig ed) New application Legacy Application Adapter 3 Adapter 2 New system Adapter 1 Extensions Legacy Application Modifications (fig ew) New system wrapper New application (fig i) Legacy Application Adapter 3 Adapter 2 Adapter 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  25. 4. IEEE standard 840-1992

  26. 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 2.2.1 Feasibility analysis 2.2.2 Detailed analysis 2.3-2.6 Control, Output, Quality factors, Metrics. 3. Design 3.1-3.6 Input, Process, Control, Output, Quality factors, Metrics. IEEE 840-1994 “Software Maintenance”Table of Contents

  27. 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 2.2.1 Feasibility analysis 2.2.2 Detailed analysis 2.3-2.6 Control, Output, Quality factors, Metrics. 3. Design 3.1-3.6 Input, Process, Control, Output, Quality factors, Metrics. 4. Implementation 4.1 Input 4.2 Process 4.2.1 Coding and & testing 4.2.3 Risk analysis & review 4.2.4 Test-readiness review 4.3-4.6 Control, Output, Quality factors, Metrics. 5. System test 5.1-5.6 Input, Process, Control, Output, Quality factors, Metrics. 6. Acceptance test 6.1-6.6 Input, Process, Control, Output, Quality factors, Metrics. 7. Delivery 7.1-7.6 Input, Process, Control, Output, Quality factors, Metrics. IEEE 840-1994 “Software Maintenance”Table of Contents

  28. Five Attributes of Each Maintenance Step (IEEE) Step 1. Problem identification 2. Analysis 3. Design 4. Implementation 5. System test 6. Acceptance test 7. Delivery

  29. Five Attributes of Each Maintenance Step (IEEE) Step Attributes 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 1. Problem identification 2. Analysis 3. Design 4. Implementation 5. System test 6. Acceptance test 7. Delivery

  30. IEEE 1219-1992 Maintenance phase 1: Problem Identification a. Input • The Maintenance Request (MR) b. Process • Assign change number • Classify by type and severity etc. • Accept or reject change • Make preliminary cost estimate • Prioritize c. Control • Identify MR uniquely • Enter MR into repository d. Output • Validated MR e. Selected quality factors • Clarity of the MR • Correctness of the MR (e.g., type) f. Selected metrics • Number of omissions in the MR • Number of MR submissions to date • Number of duplicate MR's • Time expected to confirm the problem

  31. IEEE 1219-1992 Maintenance phase 2: Problem Analysis a. Input • Original project documentation • Validated MR from the identification phase b. Process • Study feasibility of the MR • Investigate impact of the MR • Perform detailed analysis of the work required • Refine the MR description c. Control • Conduct technical review • Verify … • …test strategy appropriate • …documentation updated • Identify safety and security issues d. Output • Feasibility report • Detailed analysis report, including impact • Updated requirements • Preliminary modification list • Implementation plan • Test strategy e. Selected quality factors • Comprehensibility of the analysis f. Selected metrics • Number of requirements that must be changed • Effort (required to analyze the MR) • Elapsed time

  32. IEEE 1219-1992 Maintenance phase 3: Design a. Input • Original project documentation • Analysis from the previous phase b. Process • Create test cases • Revise … • …requirements • …implementation plan c. Control • Verify design • Inspect design and test cases d. Output • Revised … • …modification list • …detailed analysis • …implementation plan • Updated … • …design baseline • …test plans e. Selected quality factors • Flexibility (of the design) • Traceability • Reusability • Comprehensibility f. Selected metrics • Effort in person-hours • Elapsed time • Number of applications of the change

  33. EncounterEnvironment Package (Before Modification) GameEnvironment GameCharacter GameArea GameAreaConnection Area EncounterAreaConnection EncounterEnvironment EncounterEnvironment Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  34. Abstract Factory Applied to Encounter Client 1..n EncounterEnvironment EnvironmentFactory getArea() buildConnection() Area Level3Area Level3Factory getArea() getAreaConnection()

  35. Abstract Factory Applied to Encounter Client 1..n EncounterEnvironment EnvironmentFactory getArea() getConnection() Area EncounterAreaConnection Level1Area Level2Area Level3Area Level1AreaConnection Level2AreaConnection Level3AreaConnection «create» Level1Factory getArea() getAreaConnection() Level2Factory getArea() getAreaConnection() Level3Factory getArea() getAreaConnection() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  36. Migration Plan for Level-based Graphics

  37. Migration Plan for Level-based Graphics Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  38. IEEE 1219-1992 Maintenance phase 4: Implementation a. Input • Original source code • Original project documentation • Detailed design from previous phase b. Process • Make code changes and additions • Perform unit tests • Review readiness for system testing c. Control • Inspect code • Verify • CM control of new code • Traceability of new code d. Output • Updated … • …software • …unit test reports • …user documents e. Selected quality factors • Flexibility • Traceability • Comprehensibility • Maintainability • Reliability f. Selected metrics • Lines of code • Error rate

  39. 5. The management of maintenance

  40. A Typical Maintenance Flow Written MR’s Proposed M. R.’s nominal path Customer Help desk Approved M. R.’s Current source & documentation Change control board Maintenance engineer Modified source & documentation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  41. A Typical Maintenance Flow Marketing nominal path Written MR’s Proposed M. R.’s Customer Maintenance manager Help desk Approved M. R.’s Current source & documentation Change control board Maintenance engineer Modified source & documentation Rejected MR’s Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

  42. Maintenance& Patching 1. Interface with customer Help desk Complaints Marketing Docu- ment patch Patch (optional) Execute with patch

  43. Maintenance& Patching 1. Get maintenance request optional 2. Approve changes Docu- ment patch Create patch 3. Plan changes Assess impact Coordinate Execute with patch 4. Change code and documentation Implement Test changes Remove patch Document patch removal Release Update documentation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  44. Keeps customers satisfied in the short run Enables continued operation and testing without repeated prevalence of the defect Avoids masking other defects Enables test of fix Duplicates work patch and final fix both implemented Sometimes never replaced proper fix deferred forever! Complicates final fix must remove Complicates documentation process Maintenance Patches disadvantages advantages Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  45. 1. Changing priorities 2. Testing methods 3. Performance measurement 3. Incomplete or non-existent system documentation 5. Adapting to changing business requirements 6. Backlog size 7. Measurement of contributions 8. Low morale due to lack of recognition or respect 9. Lack of personnel, especially experienced 10. Lack of maintenance methodology, standards, procedures and tools . . . . . Ranked Problems in Maintenance (Deklava)

  46. Examples of Changing Priorities Top priority . . . . . . at release : • Make this most bug-free game on the market • action: eliminate as many defects as possible . . . two months after release: • Add more features than our leading competitor • action: add enhancements rapidly . . . six months after release: • Reduce spiraling cost of maintenance • action: eliminate most severe defects only Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  47. 6. Qualities in maintenance

  48. Maintenance Metrics • Number of lines of code under maintenance • Person-months to perform various maintenance tasks •  Defect count Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  49. Goal Question Selected Corresponding Metrics Note: The numbered metrics are from the IEEE. Maximize customer satisfaction How many problems are affecting the customer? • (1) Fault density • (30) Mean time to failure • Break / fix ratio • [ Number of defects introduced by maintenance actions ] / [Number of defects repaired ] How long does it take to fix a problem? • Fault closure • Average time required to correct a defect, from start of correction work. • Fault open duration • Average time from defect detection to validated correction. Where are the bottlenecks? • Staff utilization per task type: • Average person-months to (a) detect each defect and (b) repair each defect. • Computer utilization • Average time / CPU time per defect. Optimize effort and schedule Where are resources being used? • Effort and time spent, per defect and per severity category … • … planning • … reproducing customer finding • … reporting error • … repairing • … enhancing Minimize defects (continue focused development-type testing) Where are defects most likely to be found? • (13) Number of entries and exits per module • (16) Cyclotomic complexity Maintenance Metrics Classified by Goal

  50. Predicting Relative Maintenance Effort Expect high maintenance costs Expect low maintenance costs Modules: Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

More Related