1. Chapter 3: Software Maintenance Process Omar Meqdadi SE 3860 Lecture 3 Department of Computer Science and Software Engineering University of Wisconsin-Platteville

2. 2 Topic Covered Maintenance Types Maintenance Prediction Maintenance Process

3. 3 Maintenance Types Corrective Maintenance: correcting errors and bugs Adaptive Maintenance: adapting to changes in the environment (both hardware and software)  Example: Porting KDE system from Qt3 to Qt4 Perfective Maintenance: adapting to changing user requirements  Example: performance improvements, new requirements Preventive Maintenance: increasing the system’s maintainability  Example: Re-Engineering, Refactoring, and updating documentation

4. 4 Maintenance Types

5. 5 Distribution of Maintenance Types(Lientz and Swanson) corrective 21% adaptive 25% preventive 4% perfective 50%

6. Maintenance Prediction Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs  Change acceptance depends on the maintainability of the components affected by the change  Implementing changes degrades the system and reduces its maintainability  Maintenance costs depend on the number of changes and costs of change depend on maintainability

7. Maintenance Prediction

8. Change Prediction  The number of required changes  Understanding of the relationships between a system and its environment Tightly coupled systems require changes whenever the environment is changed  Factors influencing this relationship are Number and complexity of system interfaces Number of inherently volatile system requirements The business processes where the system is used

9. 9 Maintenance Process Request for change Planning phase Software comprehension Impact analysis Implementation of the change Focus of the change Change propagation Verification Documentation

10. Maintenance Process

11. Change Requests Change requests are requests for system changes from users, customers or management In principle, all change requests should be carefully analysed as part of the maintenance process and then implemented In practice, some change requests must be implemented urgently  Fault repair  Changes to the system’s environment  Urgently required business changes

12. Change Request Management Change Management to uniquely identify, describe and track the status of each requested change Change requests and their status are recorded and tracked in a Change Management Tracking System  Manage the system release  Analysis of the types and frequency of defects  Communicate to maintainers, managers and clients Project Management and the Quality Assurance team receive information about the status of the Change Requests More details in Chapter 4

13. Impact of Change Evaluate Change Requests  Identify all systems/system components affected by a change request  Evaluation of many risks associated with the change  Complexity of the change Estimate Resources  develops an estimate of the Resources needed to accomplish the change Time and schedule Cost and efforts

14. Measuring Impact of Change To measure the impact of a change, you need:  Program (Software ) Comprehension  Size of required changes LOC Number of functions, routine, and classes that will be touched  Historical information Productivity Rate, Average LOC per Routine  Time required to complete the system changes

15. Measuring Impact of Change Types of System Changes Types of Change Impacts Requirements changesAffect design, coding, and testing Document update Design changesAffect coding and tests Affect associated components Affect system architecture Affect related component interactions Implementation changesAffect test cases, test data, test scripts Affect test specification. Code change impact s - Test changes Affect other tests. Affect test documentation Document changesAffect other documents.

16. Measuring Impact of Change Program Comprehension (Covered in Chapters 8,9, &10)  The words "understanding" and "comprehension" are used as synonyms  50-90% of the maintenance time is spent in comprehension Fjelstad-Hamlen found that programmers:  studied the program 3.5 times longer than the documents  Spent more time in comprehension than in implementing enhancements  Comprehension is affected by Comprehensibility of the program Skills of the maintainer Information needs and sources

17. Measuring Impact of Change Methodologies:  Work product: any development artifact whose change is significant  Horizontal traceability: relationships of components across collections of work products  Vertical traceability: relationships among parts of a work product More details in Chapters: 8,9, & 10

18. Measuring Impact of Change Example: Horizontal Traceability

19. Change Implementation

20. Example: Corrective Maintenance includes all repairs of defects in an existing system

21. Change Implementation Example: Corrective Maintenance  Defects types: Requirements specification errors Design errors Coding errors  Facts: 80% of all problems stem from requirements and design Repairing a defect has a 20-50% change of introducing another defect Person who makes the repair is not generally the person who wrote the code

22. Change Implementation Example: Preventive Maintenance  Polish or refine the quality of the software or the documentation  Re-engineering ( Chapters 6 & 7) Rewriting and upgrading documentation Restructuring poorly written code  Fact Preventive maintenance reduces the system future maintenance costs

23. Change Implementation Example: Adaptive Maintenance  Modify software to adapt to changes in the hardware or software environment  Real Examples: Porting the KDE (K Desktop Environment) system from Qt3 to support Qt4 Modifying ABB industrial systems to deal with changes in the VxWorks and Microsoft Visual Studio (2003 to 2005)

24. Change Implementation Example: Adaptive Maintenance

25. Change Testing Only modified components need to be reviewed Develop new test cases that exercise the changes Existing and new test cases are required to test the changes Test results are compared against previous test results (Regression Testing)  More details in Chapters 11 & 12

26. System Release Deliver the system to the user System release includes:  Documentation  Source code  Hardware  Training materials  Backup procedures

27. System Release Planning Determine the contents of a system release (incremental approach) Establish the schedule of system releases Communicates between maintainers and users Plan hardware, operational procedures and backup procedures More details in Chapter 4