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. LawDescription Law of continuing change A program that is used in a real-world environment necessarily must change or become progressively less useful in that environment. Law of increasing complexity As an evolving program changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure. Law of conservation of familiarity For E-Systems to efficiently continue to evolve a deep understanding of how the system functions, and why it has been developed to function in that manner, must be preserved at all costs. The incremental change in each release over the life time of the system is approximately constant. Law of conservation of organizational stability Over a program’s lifetime, its rate of development is approximately constant and independent of the resources devoted to system development. Lehman Laws for software maintenance and evolution of large systems

10. LawDescription Law of self regulationGlobal E-type system evolution processes are self- regulating, and distribution of product and process measures close to normal. Law of continuing growth E-type system’s functional capability must be continually enhanced to maintain user satisfaction over system lifetime, BUT expansion of the system size can have negative affects to the ability to be comprehended along with its ability to evolve. Law of declining quality Poorly modified systems lead to introduction of defects; & The quality of E-type systems will appear to be declining as newer products emerge. Law of feedback system To sustain continuous change or evolution, & to minimize threats of software decay & loss of familiarity, feedback to monitor the performance is must. Feedback helps to collect metrics on the systems and maintenance efforts performance.

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. CharacteristicsDescription High maintenance cost Results due to combination of other system factors, such as complexity, poor documentation and lack of inexperienced personnel. Complex softwareResults due to structural degradation, which must have occurred over a legacy system’s lifetime of change. Obsolete support software Support software may not be available for a particular platform, or no longer be supported by its original vendor or any other organization. Obsolete hardwareLegacy system’s hardware may have been discontinued. Legacy System Characteristics

13. CharacteristicsDescription Lack of technical expertise Original developers of a legacy system are unlikely to involved with its maintenance today. Business criticalMany legacy system are essential for the proper working of the organizations which operate them. Poorly documentedDocumentation is often missing or inconsistent. Poorly understoodAs a consequence of system complexity and poor documentation, software maintainers often understand the legacy system poorly. 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. ComponentsFeatures User requirements Request for additional functionality, error correction, capability and improvement in maintainability. Request for non-programming related support. Organizational Environment Change in business policies. Competition in market. Operational Environment Hardware platform. Software specifications. Components of Software Maintenance Framework

18. ComponentsFeatures Maintenance Process Capturing requirements Variation in programming and working practices. Paradigm shift. Error detection and correction. Software Product Quality of documentation. Complexity of programs. Program Structure. Software Maintenance team Staff turnover. Domain expertise.

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. PhasesInputProcessControlOutput Problem identification phases Modification request Assign change number Classify modification request Accept or reject change Prioritize Uniquely identified modification request Enter m odification request in repository Validated modification request Validated Process determinations Analysis phases Project document Repository information Validated modification request Feasibility analysis Detailed analysis Conduct technical review Verify test strategy Verify whether the documentation is updated or not Identify security issues Feasibility report Detailed analysis report Updated requirements Preliminary modification list Test strategy Design phases Project document Source code Databases Analysis phases output Software test cases Revise requirements Revise implementation plan Software inspections/ reviews Verify design Revised modification list Revised detailed analysis Updated test plan Attributes of SMLC

26. PhasesInputProcessControlOutput Implementa- tion phases Source code System documentation Results of design phases Software code Unit test Test preparation review Software inspections/ review Updated Software Updated design documents Updated test documents Updated user documents Test preparation review report System test phase Updated software documentation Test preparation review report Updated System Functional test Interface testing Test preparation review Software code listing Modification request Test documentation Test system Test reports Acceptance test phase Test preparation review report Full integrated system Acceptance test plans Acceptance test cases Acceptance test procedures Acceptance test Inter- operability test Acceptance test Acceptance test report Delivery phase Tested/ accepted system Installation Training Version description document Version description document

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

28. Quick-fix Model 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.

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 Analyze Existing System Characterize Proposed Modifications Redesign Current Version & Implement It is a three stage cycle This model requires complete documentation as starting point of each iteration It is similar to evolutionary development paradigm 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: o redocumentation, o restructuring, o reverse engineering, and o 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 NameDescription File comparators Compares two files or systems and maintains the record for the differences in files. In addition, it determines whether the two files or the systems are identical or not. Compilers and linkers Compilers are used to check syntax errors and (in some cases) locate the type of errors. When the code is compiled, a linker is used to link code with other components, which are required for executing the program. Linkers sometimes are used to track the version numbers of the components so that appropriate versions are linked together. Debugging Allows to trace the logic of the program and examines the contents of the registers and memory areas. Cross-reference generators Assures that the changes in code are in compliance with the existing code. When a change to a requirement is requested, this tool enables one to know which other requirements, design, and code components will be affected. Static code analyzers Measures information about the code attributes, such as number of lines of codes, number of spanning paths and so on. This can be calculated when the new versions of system are developed.

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 Description of Services Provided Functional Description Reference Manual User Manual Installation Guide System Administrator Novice users Experience d users Informat ion about bug fixes Release Note System Administrator Guide Users System Administrator Getting Started with the System How to Install the System Details of all System Facilities How to Operation and Maintain the System

49. Types of User Documentation Associated with Software System Modified

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