2. CH11: Maintaining the System maintenance process can be difficult * The Changing System * The Nature of Maintenance * Maintenance Problems * Measuring Maintenance Characteristics * Maintenance Techniques and Tools * Software Rejuvenation TECH Computer Science

3. The Changing System Any work done to change the system after it is in operation is considered to be maintenance. Unlike hardware, software does not degrade or require periodic maintenance (?). Types of Systems:  S, P, E

4. Real world Problem Requirements specification System Information Comparison Subject to change S-System: the solution of the problem is well- know

5. P-System: based on a practical abstraction of the problem Real world Problem Requirements specification System Information Comparison Subject to change Abstraction

6. E-System: embedded in the real world and changes as the world does. Comparison Subject to change Problem Requirements specification System Information Abstraction Real world

7. Change During the System Life Cycle Everything Change Take change into consideration during system development. Make it easier to change during maintenance

8. The System Life Span Is it possible to build a system right the first time? Maintenance state of development is the evolutionary phase of the system. Legacy systems were built earlier when our needs and environment were different.

9. Development Time vs. Maintenance Time Typical development project takes between 1 and 2 years, but requires an additional 5 to 6 years of maintenance time! 80-20 Rule: Twenty percent of the effect is in development and eighty percent is in maintenance.

10. System Evolution vs. System Decline: When shall we discard the old system and build a new one to replace it?  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?

11. “Laws of Software Evolution”  Continuing change: changing till replacing by recreated version  Increasing complexity: structure deteriorates and complexity increases  Fundamental law of program evolution: subjected to self-regulating with statistically-determinable trends and invariances.  Conservation of organizational stability (invariant work rate): rate in a programming project is statistically invariant.  Conservation of familiarity (perceived complexity): release content of the successive releases is statistically invariant.

12. The Nature of Maintenance Corrective Maintenance: maintenance in respond to problems resulting from faults during day-to-day system usage. Adaptive Maintenance: a change introduced in one part of the system requires changes to other parts. Perfective Maintenance: make changes to improve some aspect of the system Preventive Maintenance: make change to prevent failures.

13. Use of Maintenance Time Perfective 50% Adaptive 25% Corrective 21% Preventive 4%

14. Maintenance Problems How do we balance the need for change with the need for keeping a system accessible for users? Staff Problems Technical Problems The Need to Compromise Maintenance Cost

15. Staff Problems Limited Understanding: 47% of software maintenance effect is devoted to understanding the software to be modified. User’s Limited Understanding: provide incomplete and misleading data when reporting a problem Management Priorities: view maintaining and enhancing as more (or less?) important then building new applications

16. Staff Problems: Morale 11.9% of the problems during maintenance result from low morale and productivity. During maintenance, 8% of the problems result from a programmer’s being pulled in too many directions at one, and thus being unable to concentrate on one problem long enough to solve it.

17. Technical Problems Number one problem! The y2k problem, “year 2000 problem,” is a good example of where simple but narrow design decisions can have a major effect on maintenance. Maintaining object-oriented programs can be problematic: the design often involves components that are highly interconnected by complex inheritance schemes.

18. More Technical Problems Inadequate design specifications and low-quality programs and document account for almost 10% of maintenance effort. Testing Difficulties: Testing the system in used can be a problem.  Solution: tests are often run on duplicate system

19. The Need to Compromise Programmer may be forced to compromise elegance and design principles because a change is needed immediately. The team is forced to concentrate is resources on a problem about which it may have little understanding.

20. Maintenance Cost All the problems of maintaining a system contribute to the high cost of software maintenance. Maintenance costs may be up to 80% of a system’s lifetime costs.  A series of repairs and enhancements usually leads to fragmentation of system, poor document,... -> more difficult and more effort needed for future maintenance.  Staff Specialization: leads to exponential increase in resources devoted to maintenance.

21. Measuring Maintenance Characteristics External view of maintainability: records the following info for each problem  the time at which the 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

22. Internal Attributes Affecting Maintainability the more complex the code, the more effort required to maintain it measuring how complex: Cyclomatic Number is a metric that captures an aspect of the structure complexity of source code by measuring the number of linearly independent paths through the code.

23. Finding the Cyclomatic number = edges - nodes + 2 = number of separated segments in the graph = number of decision statements in the code + 1 Cautions:  there are other attributes that contribute to complexity that are not captured by its structure

24. Graphs for Cyclomatic number calculation numdigit > 0? NO YES If numdigit = 0 n = 0? NO YES CONTROL FLOW GRAPHEQUIVALENT GRAPH

25. Readability Text: ~= number of years of schooling needed for a person to read a passage with ease and understanding Fog Index = 0.4 * number of words / number of sentences + percentage of words of 3 or more syllables Software: Readability of source code = 0.295*(average normalized length of variables) - 0.499*(number of lines containing statements) + 0.13*(Cyclomatic number)

26. Maintenance Techniques and Tools Configuration Management keeps track of changes and their effects on other system components. Impart analysis is the evaluation of the many risks associated with the change, including estimates of effects on resources, effect, and schedule.

27. Software maintenance Activities Manage software maintenance Analyze software change impact Understand software under change Implement maintenance change Account for ripple effect (Re)test affected software Preventive Adaptive Corrective Perfective NEW SYSTEM Impact/scope Traceability roadmap Complexity Modularity Documentation Self-descriptiveness Adaptability Stability Consistency Testability Verifiability Completeness Existing system Change Request

28. Workproducts and Traceability A workproduct is any development artifact whose change is significant. Vertical traceability expresses the relationship among the parts of the workproduct. Horizontal traceability addresses the relationships of the components across collections of workproducts.

29. Horizontal traceability Requirements document r1 r2 r2.2 r3. d1 d2. d1 d2. d1 d2 d3 Code m.1 Code m.2 Code m.3 Code m.4 Code m.5 Code m.6 Test t.11 Test t.12 Test t.10 Test t.1 Test t.2 Test t.3 Test t.4 Test t.5 Test t.6 Test t.7 Test t.8 Test t.9 Accep- tance test n.2... Design components Code components Tests

30. Underlying graph for maintenance D2 D1 D3 D4 D5 D6 Dk D7 D8...... R2 R1 R3 R4 R5 R6 Rj.... C2 C1 C3 C4 C5 C6 Cm C7 C8...... T2 T1 T3 T4 T5 T6 Tn T7 T8...... RequirementsDesignCodeTest

31. Complexity as result of maintenance If the number of paths in the graph increase after the change, then the system is likely to be more unwieldy and difficult to maintain. If number edges go into the node (in-degrees) and number of edges go out the node (out-degrees) increase substantially, then the system may be harder to maintain in the future.

32. Tools for Maintenance Text Editors File Comparator Compilers and Linkers Debugging Tools Cross-reference Generators Static Code Analyzers Configuration Management repositories

33. Software Rejuvenation addresses maintenance challenge by trying to increase the overall quality of an existing system Redocument: analysis of the source code to provide more info to assist maintenance. Restructure: transforming ill-structured code into well-structured one.

34. Reverse engineer Reverse engineer: recreating design and specification information from the code. Reengineering: reverse engineer then “forward engineer” to change the specification and design

35. Taxonomy of software rejuvenation SPECIFICATION DESIGN SOURCE CODE Forward Engineering forward progression through process Restructuring from code internally represent iteratively simplify structure and eliminate dead code regenerate code Redocumenting from code static analysis reports on structure, complexity, volume, data, etc. not based on software methods Reverse Engineering from code produces design and specification based on accepted software methods manages representation Reengineering from code reverse- engineer code forward- engineer: complete and modify representation regenerate code

36. Redocumentation Source code Component and variable tables Cross-reference Data interface tables Pseudocode Data and control flows Component calling hierarchy Program tree Complexity and size data Data usage Ripple- effect Test paths DesignTests Code Evaluated using static analysis Leading to additional information about:

37. Restructuring Unstructured codeStructured code Simplify internal representation Regenerate structured code Internal representation of the code

38. Source code Static analysis Data dictionary Process specifications Component calling hierarchy Pseudocode Entity-relation diagrams Data and control flow diagrams Data structure diagrams Structure charts Module and variable tables Cross-reference Data interface tables Test paths *NEW* information about, and updates to, all system artifacts Reverse Engineering

39. Reengineering Unstructured codeStructured code Reverse engineer Regenerate new system STEP 1 Specification Design Update internal specification and design STEP 2 STEP 3

40. Concluding Remark: What this course means for you Software development processes Large software projects Team Work Documentation and communication Learn the terms of the trade What to expect when you work in software development co. ($$$) (???) “Live Long and Prosper”