1. Chapter 11 Maintaining the System Shari L. Pfleeger Joann M. Atlee 4 th Edition

2. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.2 Contents 11.1 The Changing System 11.2 The Nature of Maintenance 11.3 Maintenance Problems 11.4Measuring Maintenance Characteristics 11.5Maintenance Techniques and Tools 11.6Software Rejuvenation 11.7Information System Example 11.8Real Time Example 11.9What this Chapter Means for You

3. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.3 Chapter 11 Objectives System evolution Legacy systems Impact analysis Software rejuvenation

4. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.4 11.1 The Changing System Maintenance: Any work done to change the system after it is in operation – Software does not degrade or require periodic maintenance – However, software is continually evolving – Maintenance process can be difficult

5. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.5 11.1 The Changing System Lehman’s System Types S-system: Formally defined by and derivable from a specification – Matrix manipulation P-system: Requirements are based on practical abstraction of a problem. Approximate solution exists which is acceptable if the results make sense. – Chess program E-system: Embedded in the real world and changes as the world does – Software to predict how economy functions (but economy is not completely understood)

6. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.6 11.1 The Changing System S-System S-system is static – Does not easily accommodate a change in the problem that generated the S-system

7. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.7 11.1 The Changing System P-System P-system subject to incremental change – The system resulting from the changes is NOT a new solution, rather a better solution to the existing problem – More dynamic than S- system

8. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.8 11.1 The Changing System E-System E-system is likely to undergo constant change – It is an integral part of the world it models – The changeability depends on its real-world context

9. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.9 11.1 The Changing System Changes During the System Life Cycle By examining the system in lines of its category (S,P or E), we can see where changes may occur S-system: Problem is defined and unlikely to change – If system performance is unacceptable, it is probably because it addresses wrong problem P-system: Problem definition is abstract which is addressed by approximate solution – Changes as discrepancies and omissions are identified E-system: Problem itself could change – Constant change may be required

10. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.10 11.1 The Changing System Examples of Change During Software Development Activity from which Initial change resultsArtifacts requiring consequent change Requirement analysisRequirement specification System designArchitectural design specification Technical design specification Program designProgram design specification Program implementationProgram code Program documentation Unit testingTest plans Test scripts System testingTest plans Test scripts System deliveryUser documentation Operator documentation System guide Programmer’s guide Training classes

11. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.11 The Impact of a Change 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

12. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.12 11.1 The Changing System The System Life Span Will we need maintenance (evolutionary) phase? – Even if best practices are followed, still need maintenance (because of E and P systems) Development time vs. maintenance time – Recent surveys: 20% vs 80% How much change can we expect? – System evolution vs. system decline: Better to discard old system and build a new one? Cost/reliability/adaptability to change unacceptable? – Laws of software evolution

13. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.13 11.1 The Changing System Development Time Vs. Maintenance Time Parikh and Zvegintzov (1983) – Development time: 2 years – Maintenance time: 5 to 6 years Fjedstad and Hamlen (1979) – 39% of effort in development – 61% of effort in maintenance 80-20 rule – 20% of effort in development – 80% of effort in maintenance

14. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.14 11.1 The Changing System System Evolution vs. Decline (significant and continual change) Is the cost of maintenance too high? Is the system reliability unacceptable? Can the system no longer adapt to further change and within a reasonable amount of time? Is system performance still beyond prescribed constraints? Are system functions of limited usefulness? Can other systems do the same job better, faster or cheaper? Is the cost of maintaining the hardware great enough to justify replacing it with cheaper, newer hardware?

15. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.15 11.1 The Changing System Laws of Software Evolution Continuing change (a SW must change or becomes less useful) Increasing complexity: Structure deteriorates Fundamental law of program evolution: Program obeys statistically-determined trends and invariants (size, time between releases, number of errors, …) Conservation of organizational stability: Global activity rate in a programming project is statistically invariant Conservation of familiarity: release content (changes) of the successive releases of an evolving program is statistically invariant

16. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.16 11.1 The Changing System Sidebar 11.1 Bell Atlantic (Verizon) Replaces Three Systems with One Evolving One Sales Service Negotiation System (SSNS) – Replaced three legacy systems in 1993 – The goals of the system changed from order-taking to needs-based sales – Replaced archaic commands with plain English – Originally written in C and C++, the system was modified with Java

17. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.17 11.2 The Nature of Maintenance Types of Maintenance Corrective: Maintaining control over the system’s day-to-day functions – Temporary fixes or long-range changes to address any failures Adaptive: Maintaining control over system modifications Perfective: Perfecting existing acceptable functions Preventive: Preventing system performance from degrading to unacceptable levels – Tracing potential faults that has not yet become a failure

18. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.18 11.2 The Nature of Maintenance Who Performs Maintenance Part of development team – Will build the system in a way that makes maintenance easier – May feel over confident and ignore the documentation to help maintenance effort Separate maintenance team – May be more objective – May find it easier to distinguish how a system should work from how it does work

19. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.19 11.2 The Nature of Maintenance Maintenance Team Responsibilities Understanding the system Locating information in system documentation Keeping system documentation up-to-date Extending existing functions to accommodate new or changing requirements Adding new functions to the system Finding the source of system failures or problems Locating and correcting faults Answering questions about the way the system works Restructuring design and code components Rewriting design and code components Deleting design and code components that are no longer useful Managing changes to the system as they are made

20. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.20 11.2 The Nature of Maintenance Use of Maintenance Time Graphical representation of distribution of maintenance effort (Lientz and Swanson)

21. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.21 11.3 Maintenance Problems Staff Problems Limited understanding (the importance of documentation) – 47% of effort is spent on understanding – For a system with m components and k changes, there are k*(m - k) + k*(k - 1)/2 interfaces to be evaluated Management priorities – Rushing a new product to the market vs. taking time to follow good SE practices Morale: “Second-hand” status accorded to maintenance team – Maintenance process requires skill in writing code, in working with users, in anticipating change, in sleuthing

22. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.22 11.3 Maintenance Problems Technical Problems Artifacts and paradigms (e.g., legacy, non-OO) – OO systems can be difficult (highly interconnected components via complex inheritance) Testing difficulties – Some systems must be available around the clock (e.g., airline reservation) – Adequate test data may not be available for testing the changes made – Effects of design or code changes are difficult to be predicted and to be prepared for

23. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.23 11.3 Maintenance Problems The Need to Compromise Balancing act: The need for change vs. the need for keeping the system available to users – Principles of SE compete with expediency and cost Fixing problem: Quick but inelegant solution or more involved but elegant way General-purpose code vs. special-purpose code

24. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.24 11.3 Maintenance Problems Factors Affecting Maintenance Approach The type of failures The failure’s critically or severity The difficulty of the needed changes The scope of the needed changes The complexity of the components being changed The number of physical locations at which the changes must be made

25. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.25 11.3 Maintenance Problems Sidebar 11.2 The Benefits and Drawbacks of Maintaining OO Systems Benefits – Maintenance changes to a single object class may not affect the rest of the program – Maintainers can reuse objects easily Drawbacks – OO techniques may make programs more difficult to understand – Multiple parts can make it difficult to understand overall system behavior – Inheritance can make dependencies difficult to trace – Dynamic binding makes it impossible to determine which of several methods will be executed – By hiding the details of data structure, program function is often distributed across several classes

26. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.26 11.3 Maintenance Problems Sidebar 11.3 Balancing Management and Technical Needs at Chase Manhattan Relationship Management System (RMS) – Developed by Chemical Bank, and then modified and merged with Global Management System – Combined with other systems to eliminate duplication and link hardware platforms and business offices – Windows-based GUI was developed – Modified to allow it to run spreadsheets and print reports using Microsoft products – Incorporated Lotus Notes

27. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.27 11.3 Maintenance Problems Maintenance cost Factors affecting maintenance effort – Application type (real-time?) – System novelty (new application?) – Turnover and maintenance staff availability – System life span (developed for long life?) – Dependence on a changing environment (E-system?) – Hardware characteristics (Unreliable hardware?) – Design quality – Code quality – Documentation quality – Testing quality

28. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.28 11.3 Maintenance Problems Modeling Maintenance Effort: Belady and Lehman Staff specialization (no generalist) leads to an exponential increase in resources devoted to maintenance Fault correction might introduce new system faults and change the system structure M = p + Ke c-d – M: Total maintenance effort – p: Productive efforts: analysis, design, coding and testing – c: Complexity because of poor design – d: Degree of familiarity – K: Empirical constant – e: mathematical constant e

29. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.29 11.3 Maintenance Problems Modeling Maintenance Effort: COCOMO II Size = ASLOC (AA + SU + 0.4DM + 0.3CM + 0.3IM)/100 – ASLOC: Number of source lines of code to be adapted – AA: Assessment and assimilation effort – SU: Rating scale that represents amount of software understanding required – DM: Percentage of design to be modified – CM: Percentage of code to be modified – IM: Percentage of external code (ex: reused code) to be integrated

30. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.30 11.3 Maintenance Problems COCOMO II Rating for Software Understanding (SU) Very lowLowNominalHighVery high StructureVery low cohesion, high coupling, spaghetti code Moderately low cohesion, high coupling Reasonably well structured, some weak area High cohesion, low coupling Strong modularity, information hiding in data and control structure Application clarity No match between program and application worldviews Some correlation between program and application Moderate correlation between program and application Good correlation between program and application Clear match between program and application worldviews Self descriptiveness Obscure code; documentation missing, obscure, or obsolete Some code commentary headers; some useful documentatio n Moderate level of code commentary headers, and documentation Good code commentary and headers; useful documentation ; some weak areas Self descriptive code; documentation up-to-date, well organized, with design rationale SU increment5040302010

31. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.31 11.3 Maintenance Problems COCOMO II Ratings for AA Effort (to assess/change code) Assessment and Assimilation Increment Level of Assessment and Assimilation Effort 0None 2Basic component search and documentation 4Some component test and evaluation documentation 6Considerable component test and evaluation documentation 8Extensive component test and evaluation documentation

32. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.32 11.4 Measuring Maintenance Characteristics During maintenance process, measures can help us – Evaluate the impact of a change or – Assess the relative merits of several proposed changes Maintainability covers not only code, but also specification, design and test plan documentations Maintainability can be viewed in two ways – External view of the software: Measuring maintainability by monitoring the software’s behavior Proposed usage of software, person performing maintenance, supporting documentation and tools – Internal view of the software: Measuring before delivery

33. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.33 11.4 Measuring Maintenance Characteristics External View of (Measuring) Maintainability Necessary measures – The time at which problem is reported – Any time lost due to administrative delay – The time required to analyze the problem – The time required to specify which changes are to be made – The time needed to make the change – The time needed to test the change – The time needed to document the change Other measures – The ratio of total change implementation time to total number of changes implemented – The number of unresolved problems – The time spent on unresolved problems – The percentage of changes that introduce new faults – The number of components modified to implement a change

34. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.34 11.4 Measuring Maintenance Characteristics External View of Maintainability (continued) Graph illustrates the mean time to repair the various subsystems for software at a large British firm

35. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.35 11.4 Measuring Maintenance Characteristics In ternal Attributes Affecting Maintainability Cyclomatic number (McCabe, 1976) – A metric that captures the structural complexity of the source code – Measuring linearly independent paths through the code – Based on graph theoretic concept In maintenance, this number gives an idea as to how much we have to understand and track NOTE: There are attributes other than the structure that contribute to the complexity – Ex: Inheritance hierarchy of OO program

36. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.36 11.4 Measuring Maintenance Characteristics Example for Calculating Cyclomatic Number Consider the following code Scoreboard::drawscore(int n) { while(numdigits-- > 0} { score[numdigits]->erase(); } // build new score in loop, each time update position numdigits = 0; // if score is 0, just display “0” if (n == 0) { delete score[numdigits]; score[numdigits] = new Displayable(digits[0]); score[numdigits]->move(Point((700-numdigits*18),40)); score[numdigits]->draw(); numdigits++; } while (n) { int rem = n % 10; delete score[numdigits]; score[numdigits] = new Displayable(digits[rem]); score[numdigits]->move(Point(700-numdigits*18),40)); score[numdigits]->draw(); n /= 10; numdigits++; }

37. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.37 11.4 Measuring Maintenance Characteristics Example for Calculating Cyclomatic Number (continued) Linearly independent path = e - n + 2 – e: edges, n : nodes

38. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.38 11.4 Measuring Maintenance Characteristics Other Measures Fog index: Textual products, readability affects maintainability – F = 0.4 X (number of words/number of sentences) + percentage of words of three or more syllables De Young and Kampen readability – R = 0.295a – 0.499b + 0.13c a : the average normalized length of variable b: number of lines containing statements c : McCabe’s cyclomatic number

39. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.39 11.4 Measuring Maintenance Characteristics Sidebar 11.4 Models of Fault Behavior Hatton and Hopkins (1989) studied the NAG Fortran scientific subroutine library – Smaller components contained proportionately more faults than larger ones They notes similar evidence at – Siemens – Ada code at Unisys – Fortran products at NASA Goddard

40. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.40 11.4 Measuring Maintenance Characteristics Sidebar 11.5 Maintenance Measures at Hewlett-Packard Used maintainability index – Index was calibrated with a large number of metrics – A tailored polynomial index was calculated using extended cyclomatic number, lines of code, number of comments and an effort measure – The polynomial was applied to 714 components containing 236,000 lines of C code developed by a third party

41. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.41 11.5 Maintenance Techniques and Tools Configuration management – Configuration control board – Change control Impact analysis Automated maintenance tools

42. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.42 11.5 Maintenance Techniques and Tools Configuration Control Process Problem discovered by or change requested by user/customer/developer and recorded Change reported to the configuration control board(CCB) CCB discusses problem: determines nature of change, who should pay CCB discusses source of problem, scope of change, time to fix; they assign – severity/priority to request – analyst to make appropriate changes Analyst makes changes on test copy Analyst works with librarian to control installation of change Analyst files a change report describing all the changes in detail

43. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.43 11.5 Maintenance Techniques and Tools Change Control Issues (must know the state of any component) Synchronization: When was the change made? Identification: Who made the change? Naming: What components of the system were changed? Authentication: Was the change made correctly? Authorization: Who authorized that the change be made? Routing: Who was notified of the change? Cancellation: Who can cancel the request for change? Delegation: Who is responsible for the change? Valuation: What is the priority of the change?

44. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.44 11.5 Maintenance Techniques and Tools Impact Analysis The evaluation of the many risks associated with the change, including estimates of effects on resources, effort and schedule Helps control maintenance costs

45. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.45 11.5 Maintenance Techniques and Tools Software Maintenance Activities Graph illustrates the activities performed when a change is requested

46. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.46 11.5 Maintenance Techniques and Tools Measuring Impact of Change Workproduct: Any development artifact whose change is significant Vertical traceability: The relationships among parts of a workproduct (e.g. among the requirements) Horizontal traceability: The relationships of the components across collections of workproducts (design, code, …) Can represent as a directed graph

47. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.47 11.5 Maintenance Techniques and Tools Horizontal Traceability in software workproducts The graphical relationships and traceability links among related workproducts

48. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.48 11.5 Maintenance Techniques and Tools Underlying Graph for Maintenance

49. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.49 11.5 Maintenance Techniques and Tools Sidebar 11.6 Applying Traceability to Real-World System Applied to an OO dev. project at Ericsson Radio Systems Implemented five kinds of traceability – object-to-object – association-to-association – use case-to-use case – use case-to-object – two-dimensional object-to-object (incorporating inheritance) How tracing is performed – Using explicit links – Using textual references to different documents – Using names and concepts that are the same and similar – Using knowledge and domain knowledge

50. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.50 11.5 Maintenance Techniques and Tools Automated Maintenance Tools Many automated tools exist to track the status of all components – Text editors – File comparators – Compilers and linkers – Debugging tools – Cross-reference generators – Static code analyzers – Configuration management repositories

51. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.51 11.5 Maintenance Techniques and Tools Sidebar 11.7 Panvalet Incorporates the source code, object code, control language and data files needed to run a system Controls more than one version of a system – A single version is designated as the production version and no one is allowed to alter it Places the version number and date of last change on the compiler listing and object module automatically when a file is compiled Has reporting, backup and recovery features plus three levels of security access

52. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.52 11.6 Software Rejuvenation In many organizations with large amounts of software, maintaining those systems is a challenge Software rejuvenation addresses this maintenance challenge by trying to increase the overall quality of an existing system There are several aspects of software rejuvenation – Redocumentation – Restructuring – Reverse engineering – Reengineering

53. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.53 11.6 Software Rejuvenation (continued) Redocumentation: Static analysis adds more information Restructuring: Code transformation to improve code structure Reverse engineering: Recreation of design and specification information from the code Reengineering: Reverse engineer and then make changes to specification and design to complete the logical model; then generate new system from revised specification and design

54. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.54 11.6 Software Rejuvenation Taxonomy of software rejuvenation Graph illustrates the relationship among the four types of rejuvenation

55. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.55 11.6 Software Rejuvenation Redocumentation Begins by submitting the code to an analysis tool Output may include: – Component calling relationships – Class hierarchies – Data-interface tables – Data-dictionary information – Data flow tables or diagrams – Control flow tables or diagrams – Pseudocode – Test paths – Component and variable cross-references

56. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.56 11.6 Software Rejuvenation Redocumentation Process Redocumentation process

57. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.57 11.6 Software Rejuvenation Restructuring Activities Interpreting the source code and representing it internally Using transformation rules to simplify the internal representation Regenerating structured code

58. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.58 11.6 Software Rejuvenation Restructuring Activities (continued) Graph illustrates the three major activities involved in restructuring: (1) static analysis (2) simplification of the internal representation (3) refined representation used to generate a structured version

59. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.59 11.6 Software Rejuvenation Reverse Engineering Attempting to recover engineering information based on software specification and design methods Obstacles remain before reverse engineering can be used universally – Real time system problem – Extremely complex system Successful when expectations are low

60. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.60 11.6 Software Rejuvenation Reverse Engineering Process Graph depicts the reverse-engineering process

61. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.61 11.6 Software Rejuvenation Reengineering An extension of reverse engineering – produces new software code without changing the overall system function Reengineering steps – The system is reverse-engineered – The software system is corrected or completed – The new system is generated

62. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.62 11.6 Software Rejuvenation Reengineering Process Graph illustrates the steps in reengineering process

63. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.63 11.6 Software Rejuvenation Sidebar 11.8 Reengineering Effort The U.S National Institute of Standard and Technology (NIST) studied the results of reengineering 13,131 lines of COBOL source statements using automatic translation – Entire reengineering effort took 35 person-month Boehm point out that original COCOMO model estimated 152 person months for reengineering the same type of system, clearly unacceptable level of accuracy – COCOMO II has been revised to include a factor for automatic translation

64. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.64 11.7 Information System Example Piccadilly System The software can not be an S-system – the problem may change dramatically The software can not be a P-system – P-system requires a stable abstraction, while Piccadilly changes constantly The software must be a E-system – The system is an integral part of the world it models

65. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.65 11.8 Real-Time Example Ariane-5 Developers focused on mitigating random failure – The inertial reference system failed because of a design fault, not a result of a random failure Needs to change the failure strategy and implement a series of preventive enhancements

66. Pfleeger and Atlee, Software Engineering: Theory and PracticeChapter 11.66 11.9 What this Chapter Means for You The more a system is linked to the real world, the more likely it will change and the more difficult it will be to maintain Maintainers have many jobs in addition to software developers Measuring maintainability is difficult Impact analysis builds and tracks links among the requirements, design, code and test cases Software rejuvenation involves redocumenting, restructuring, reverse engineering and reengineering