Software Maintenance

1. Software Maintenance

2. OBJECTIVES • To appreciate need of Software maintenance performed. • To understand reasons for change taking place in a software system. • To appreciate the concept of legacy system. • To know Software maintenance prediction. • To list various factors which adversely affect software maintenance. • To know types of software maintenance, viz. corrective, adaptive, perfective, and preventive maintenance. • To understand the Software maintenance life cycle.

3. OBJECTIVES • To know various software maintenance models, viz. quick-fix, iterative enhancement and reuse model. • To understand various techniques for maintenance, such as configuration management, impact analysis and software rejuvenation. • To list various tools that assist in maintaining the software. • To appreciate need for technology change management, which is a process of identifying, selecting and evaluating new technologies. • To understand software maintenance documentation.

4. CONTENTS • Basics of software maintenance • Types of software maintenance • Software maintenance life cycle • Software maintenance Models • Techniques for maintenance • Tools for Software maintenance • Technology change management(TCM) • Software maintenance documentation.

5. BASICS OF SOFTWARE MAINTENANCE • IEEE defines maintenance as : • ‘A process of modifying a software system or component after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a changed environment’. • In software engineering a software needs to be ‘serviced’ so that it is able to meet the changing • environment (such as business and user needs) where it functions this servicing of software.

6. Providing Continuity of Service Fixing errors, recovering from failures, such as hardware failures or incompatibility of hardware with software, and accommodating changes in the operating system and the hardware. • Supporting Mandatory Upgrades Due to changes in government regulations or students to maintain competition with other software that exist in the same category. • Improving the Software to Support User Requirements To enhance functionality in a software, to improve performance .

7. Facilitating Future Maintenance Work Include restructuring of the software code and database used in the software. • Improving the Software to Support User Requirements To enhance functionality in a software, to improve performance . • Facilitating Future Maintenance Work Include restructuring of the software code and database used in the software.

8. Changing a Software System • Software maintenance and evolution of system was first introduced by Lehman. • One of the key observations of the studies was that large system are never complete and continue to evolve and as these system evolve, they become more complex unless some actions are taken to reduce the complexity. • Lehman stated five laws for software maintenance and evolution of large systems.

9. Lehman Laws for software maintenance and evolution of large systems

10. Lehman Laws for software maintenance and evolution of large systems

11. Legacy Systems • Were developed before the introduction of structured programming . • Process models and basic principles such as modularity coupling, cohesion, good programming practice emerged too late for them. • Legacy system are generally associated with high maintenance costs. • The root cause of this expense is the degraded structure that results from prolonged maintenance.

12. Legacy System Characteristics

13. Legacy System Characteristics

14. Software Maintenance Prediction

15. Software Maintenance Prediction • The various predictions shown in the figure are closely related and specify the following: • The decision to accept a system change depends on the maintainability of the system components affected by that change up to a certain extent. • Implementing change degrades the system structure and hence reduces its maintainability. • Costs involved in implementing change depend on the maintainability of system components.

16. Process metrics are used to predict software maintainability. Some of the useful Process metrics are: • Corrective maintenance: While fixing failures some times more errors are introduced rather than being repaired. This shows decline in maintenance. • Average time required for impact analysis: The time that goes into analysis of impact of modifications before starting the software maintenance. • Number of outstanding change requests: Increasing number of outstanding change requests with time implies decline in maintainability. • Average time to implement a change request: If the time taken to implement the change in software and its documentation, rather than impact assessment, increases, it implies decline in maintainability.

17. Components of Software Maintenance Framework

18. Components of Software Maintenance Framework

19. Factors Affecting Software Maintenance • Relationship of Software product and Environment • Relationship of Software product and User • Relationship of Software product and Software Maintenance team • Software Maintenance team

20. Software Maintenance Team: • Various functions performed by the Software Maintenance team are: • 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 • Managing change to the system as they are made. • The aspects of a maintenance team that lead to high maintenance costs are: • Staff turnover • Domain expertise

21. TYPES OF SOFTWARE MAINTENANCE • Corrective maintenance is concerned with fixing reported errors in the software. • Adapting maintenance means changing the software to some new environment, such as adapting a new version of an operating system. • Perfective maintenance involves implementing new functional or non-functional requirements. • Preventive maintenance involves implementing, changes to prevent occurrence of errors.

22. Types of Software Maintenance

23. Phases of Software Maintenance Life Cycle

24. Attributes of Software Maintenance Life Cycle

25. Attributes of SMLC

27. SOFTWARE MAINTENANCE MODELS • Quick-fix model. • Boehm’s model • Osborne’s model • Iterative enhancement model. • Reuse-oriented model.

28. Identify problem & fix it as quickly as possible • No analysis of effects is made, and there is little or no documentation to use • Gets work done quickly with lower cost • In Quick-fix model starting point of maintenance is always source code. Quick-fix Model

29. Boehm's model: Economic Model • Maintenance process represented as a closed loop cycle • Maintenance process is driven by the maintenance manager’s decisions, which are based on the balancing of objectives against the constraints • It is the stage where management decisions are made that drives the process • In the stage, asset of approved changes is determined by applying particular strategies and cost-benefit evaluations to a set of proposed changes. The approved changes are accompanied by their own budgets

30. Osborne’s Model • It deals directly with the reality of the maintenance environment, where as other models tend to assume some facet of an ideal situation - the existence of full documentation, for example. • The maintenance model is treated as continuous iterations of the software life-cycle with, at each stage, provision made for maintainability to be built in. • If good maintenance features already exist, for example full and formal specification or complete documentation, all well and good, but if not, allowance is made for them to be built in. • Many technical problems which arise during maintenance are due to inadequate management communications and control • The Model

31. Iterative Enhancement Model This model requires complete documentation as starting point of each iteration It is similar to evolutionary development paradigm It is a three stage cycle Existing documentation for each stage is: - Requirement documentation, Design Documentation, Source code documentation, & Test documentation

32. Iterative Enhancement Model

33. The Reuse-Oriented Model • Maintenance is viewed as the activity involving the reuse of existing program components. • It builds a component library for reusing requirements, design, source code, and test-data. • A detailed framework is required for classification of components for reuse.

34. Reuse-oriented Model Component Library

35. The Reuse-oriented Model has 4 main steps: • Identifying the parts of the old system which have the potential for reuse, • Fully understanding the system parts, • Modifying the old system parts according to the new requirements, and • Integrating the modified parts into the new system.

36. TECHNIQUES FOR MAINTENANCE • Configuration Management • In organizations Configuration Control Board (CCB) is constituted to oversee the entire change process. • Request for change is received on a formal change request form. • The change control form should include information about how the system works, nature of the problem, and how the new (expected) system should work. • The request for change is reported to the Configuration Control Board. • The representative of CCB meets the user to discuss the problem.

37. Configuration Management – Cont…. • When the user requests for a reported failure, the CCB discusses the source of the problem. • If the requested change is an enhancement, the CCB discusses the parts or the components that will be affected by the change. • In both the cases, developers describe the scope of change and the expected time to implement them. • Finally, all the relevant documentation is updated according to the requested change. • The developers then record all the changes made to the operational system in a change report to keep track of the next release or version of the software system.

38. Software Versions • Version control implies the process by which the contents of the software, hardware, or documentation are revised. • Not that the software configuration management manages how the versions differ, who made the changes, and why they were made. • The records, such as name of the component, date and time, version status, and account of all changes are managed. • This helps the software configuration management to identify the current version and the revised number of the operational system.

39. Impact Analysis • Impact analysis is used to evaluate risks associate with change. Includes estimating effect on effort schedule, and resources. Impact analysis is also used to determine the consequences of making modifications in the software system and to analyze the cost and benefits of the modifications. • Advantages of Impact Analysis are: • To understand situations when the modifications required in the software system affect large segments of software code or several components of the software. • To understand relationship of the components that are to be modified along with the structure of the software. • To record the history of modification, which helps in maintaining quality in the software system.

40. Software Rejuvenation • May include enhancing or completely replacing a software system. To preserve or increase the software quality, and its maintainability while keeping the costs low. • Four types of software rejuvenation exist, namely: • redocumentation, • restructuring, • reverse engineering, and • re-engineering.

41. Redocumentation • To produce additional information, which helps the software maintenance team to understand and refer to the code. • In source code, components size, component calls, calling parameters, and control paths are examined to understand what and how code does it. • The output of static code analysis is either graphical or textual, which can be used to assess whether or not redocumentation is required.

42. Restructuring Involves transformation of unstructured code into structured code. Restructuring involves the following steps: • Static analysis is performed, which provides information that is used to represent code as directed graph or associative (semantic) network. The representation may or may not be in a human readable form; thus, an automated tool is used. • Transformation techniques are used to refine (simplify) the representation. • Refined representation is interpreted and used to generate the structured code.

43. Reverse Engineering • Focuses on providing information about the specification and design information using the software code. • Reverse Engineering involves the following steps: • Source code is collected with the help of an automated tool used for reverse engineering. This tool is used to represent the structure and the naming information of variable, functions and other components in the software code. • Static analysis is performed. • Some methods, such as ‘structure analysis and design’ methods are used. These methods are used to extract information such as data dictionaries, data-flow, control flow, and entity relationship (ER) diagram for the reverse engineering technique.

44. Re-engineering : is extension of reverse engineering : Re-engineering refers to the systematic transformation of the present software system into a new form to make quality improvements in operation, system capability, functionality, and achieving high performance at low costs. Reverse Engineering involves the following steps: • The system is reverse engineered and represented internally for human and computer modifications. • The software system is corrected and completed. This includes updating internal specification and design. • Using new specification and design, a new system is generated.

45. Software Maintenance Tools

46. TECHNOLOGY CHANGE MANAGEMENT (TCM) • To incorporate new technology into business activities, technology change management is used. • Technology change management is a process of identifying, selecting and evaluating new technologies (such as tools, methods, and process) to incorporate the most effective technology in a software system.

47. Software Maintenance Documentation 1.0 Scope 1.1 Application 2.0 Content 2.1 System description 2.2 System diagram 2.3 System logic and date flow 2.4 program/data module description - Structured charts - Module names - Functions and calling procedure - Data structure description - Program module inputs - program outputs - Program interfaces - Tables - Files - Structured pseudocode 2.5 Operating environment - Hardware - Supporting software + Operating System + Compiler/ assembler + Other software - Database 2.6 Software maintenance procedures - Programming conventions - Source library maintenance procedures - Test and verification procedures

48. Types of user Documentation Associated with Software System Modified System Evaluators System Administrator Novice users Experienced users System Administrator Users Functional Description Installation Guide User Manual Reference Manual System Administrator Guide Release Note Description of Services Provided How to Install the System Getting Started with the System Details of all System Facilities How to Operation and Maintain the System Information about bug fixes

49. Types of User Documentation Associated with Software System Modified

50. Thanks… Adapted from: 1- Software Engineering: Principles and Practice, By RohitKhurana, Vikas Publishing House, Delhi 2- Software Maintenance Concepts & Practices, 2nd edition, by Penny Grubb and Armstrong A. Takang