1. Maintenance When the system is complete and deployed the system is operational. The work done on the operational system is called maintenance.

2. Types of Maintained Systems Real World Problem Requirements System Information Real World Problem Requirements System Information Problem Abstraction Requirements System Information Abstraction S-system: well- defined problem has an exact solution P-system: well- defined problem, approx. solution E-system: ill- defined / changing problem

3. Changes During the Life Cycle S-System: minimal changes, solution is fixed and stable. But it could be possible that we have solved the wrong problem. P-System: solution evolves as we identify changes, discrepancies and omissions. E-System: our understanding and / or nature of the problem changes, and so is the solution.

4. Planning a Maintainable System Is it possible to build the right system the first time? If not then identify system type and design it with the maintenance in mind (99% of all the cases). Alternatively one can plan on delivering a series of software systems in stages deploying new systems and retiring legacy ones. But this still does not eliminate maintenance on deployed systems! Development effort - 20%, maintenance 80%.

5. System Retiring Considerations Questions: Is the cost of software maintenance to high? Is the cost of hardware maintenance to high? Is the reliability too low? Is the change time too long (i.e. low maintainability )? Is the performance unacceptable? Why? We did not design the system with maintenance and expansion in mind. Refactoring degraded system quality. Original developers / analysts left and did not leave adequate documentation! Solution: Design a new system if the development & projected maintenance costs are lower than that for the current system in the long run.

6. Laws of Software Evolution 1.Software changes never stop. 2.Software complexity increases. 3.Work never stops and progresses at constant rate (do not fire your developers!) 4.The knowledge of the system stays at overall constant level (keep your experts!).

7. Types of Maintenance Corrective: bug fixes & regression testing. Adaptive: changes in one part of the system require changes in related components. Perfective: system performance, precision or other qualities are improved. Preventive: the failure has not yet occurred, but you are aware of conditions that may cause it.

8. Maintenance Activities 1.Alanizins & understanding the System! (always) 2.Locating info in system docs (always). 3.Keeping system docs up to date (always). 4.Extending system functions to accommodate new or changing requirements (occasionally). 5.Analyzing the impact of the changes (always). 6.Adding new functions (occasionally). 7.Finding the source of system failures or problems. 8.Correcting the faults (frequently). 9.Regression testing (always). 10.Refactoring code and design (sometimes). 11.Rewriting code and components (rarely). 12.Deleting unneeded functions (very rarely). 13.Keeping track of bugs, changes and maintenance.

9. Maintenance Problems Lack of Understanding -Complex System -Poorly written, unclear, non- standard, non-commented code -Poor / incomplete / incorrect / missing documentation -Design decisions not documented -Original developers & analysts left

10. Maintenance Problems, Cont’d Improper Management -Poor change tracking -Poor source / version control -Incomplete impact analysis -Poor / missing regression testing -Insufficient staffing -No QA environment / process

11. Maintenance Problems, Cont’d Improper Design -System not designed with maintenance in mind -System expandability is poor -Interdependencies galore -Complexity galore -Patchwork code, design -Major design or requirements errors (e.g. Y2K, 16-bit)

12. Object Oriented System Notes + Maintenance on a class is not likely to affect other classes directly, but… -Maintenance on a base class could have profound impact that is nearly impossible to track. -Inheritance makes dependencies difficult to trace. -Dynamic binding makes impact assessment extremely difficult. -Interface changes require much adaptive maintenance.

13. Application Type Impact -Real-time / critical software can be replaced only when it has been readied and tested in an equivalent environment from which a switch- over can occur -Enterprise software requires a series of regression testing of all corroborating components and a copy of production environment -High profile / cost software requires beta testing of major releases

14. Other Maintenance Issues System novelty (technologically or process-wise) severely downweights prior experience. Personnel turnover decreases maintainability. Long lifespan systems require more maintenance (proportionally to service time). Environment changes for E-systems and problem changes for P-systems are uncontrollable. Hardware maintenance & upgrades trigger software maintenance & upgrades. Component interdependency & poor design cause side-effects that even when caught by regression testing could be hard to fix. Documentation needs to updated and maintained!

15. Maintenance Time + Fault report & administrative delay + Fault analysis + Test case analysis + Fault reproduction + Code analysis + Code correction + Unit testing + Regression testing + Source & version control + Fault & fix documentation (for support) + System documentation update (for changes)

16. Attributes Affecting Maintainability Cyclomatic number: metric capturing the complexity of the code that corresponds to the number of independent paths through the code. The lower the better! Readibility / Fog Index: F = 0.4*words/sentences + % of words with 3+ syllables

17. Cyclomatic Number Example C = 3

18. Bug Fix / Change Process 1)Tech support receives a fault report and documents the fault scenario. 2)Tech support attempt to reproduce the fault in lab conditions. 3)Manager assigns analyst / developer to work out a solution. 4)Analysts reports the solution and its impact back to manager. 5)Depending on the impact & cost manager makes a decision either to fix or come up with a work-around. 6)For a fix manager makes a decision to issue a patch (critical) or implement the fix in the next release (non-critical), assigns developer to the task. 7)Developer checks out the code for the software version to which the patch applies or implements the fix in the new release project. 8)Developer conducts unit testing, passes the code to the test team. 9)Testers conduct system and regression testing, notify the developer of the uncovered issues. 10)Upon successful test developer communicates changes to tech writers. 11)Tech writers update the documentation. 12)Tech support updates the bug knowledge base documenting the solution. 13)Manager closes the bug report.

19. Impact Analysis Evaluation of many risks associated with the change, including estimates of effects on dependent components, resources, effort, and schedule. Vertical traceability expresses the relationships among the workproducts (e.g. process steps). Horizontal traceability expresses the relationships among the components within the work products (i.e. workproduct interdependency).

20. Software Rejuvenation -Rewriting to improve maintainability, readibility, performance -Rewriting using newer technologies -Rewriting to provide better interface -Redesigning / reengineering to improve maintainability, expandability, performance -Reverse engineering to obtain knowledge -Redocument the system via conducting static & dynamic analysis of the code and system operation

21. Final Advice 1)If it ain’t broke ain’t fix it! 2)Simplicity is the key. 3)Design with expandability in mind (i.e. know the limitations!) 4)Every change requires testing. 5)Delegate decision making to management but provide information needed to make a decision. 6)Do not rewrite for the sake of technology. 7)Document everything, especially the changes!

22. Read Chapter 11 from the white book.