Slide 1

SoftwareMaintenance 1OBJECTIVES

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.

2OBJECTIVES

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.

3CONTENTS

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

4 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.

5Providing Continuity of ServiceFixing 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 .

6Facilitating Future Maintenance WorkInclude restructuring of the software code and database used in the software.

Improving the Software to Support User RequirementsTo enhance functionality in a software, to improve performance .

Facilitating Future Maintenance WorkInclude restructuring of the software code and database used in the software.

7

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.

8LawDescriptionLaw 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 complexityAs 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 familiarityFor 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 stabilityOver a programs 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

9Lehman Laws for software maintenance and evolution of large systems

LawDescriptionLaw of self regulationGlobal E-type system evolution processes are self-regulating, and distribution of product and process measures close to normal.Law of continuing growthE-type systems 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 qualityPoorly 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 systemTo 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.10

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.

11

CharacteristicsDescription

High maintenance cost Results due to combination of other system factors, such as complexity, poor documentation and lack of inexperienced personnel. Complex software Results due to structural degradation, which must have occurred over a legacy systems lifetime of change.Obsolete support softwareSupport software may not be available for a particular platform, or no longer be supported by its original vendor or any other organization.Obsolete hardwareLegacy systems hardware may have been discontinued. Legacy System Characteristics12

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 documented Documentation 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 Characteristics13 Software Maintenance Prediction

14

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.

15Process 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.

16ComponentsFeaturesUser 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 Framework17Components of Software Maintenance FrameworkComponentsFeaturesMaintenance Process Capturing requirementsVariation 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. 18Factors Affecting Software Maintenance

Relationship of Software product and Environment Relationship of Software product and UserRelationship of Software product and Software Maintenance team

Software Maintenance team

19Software 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

20 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.

21 Types of Software Maintenance

22 Phases of Software Maintenance Life Cycle

23Attributes of Software Maintenance Life Cycle

24Phases InputProcessControlOutputProblem identification phases Modification requestAssign change numberClassify modification request Accept or reject change Prioritize Uniquely identified modification request Enter modification request in repositoryValidated modification request Validated ProcessdeterminationsAnalysis phases Project document Repository information Validated modification request Feasibility analysis Detailed analysisConduct 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 strategyDesign phases Project document Source code DatabasesAnalysis phases output Software test cases Revise requirements Revise implementation plan Software inspections/ reviews Verify design Revised modification list Revised detailed analysis Updated test planAttributes of SMLC25Phases InputProcessControlOutputImplementa-tionphases

Source code System documentation Results of design phasesSoftware code Unit testTest preparation reviewSoftware inspections/ review Updated Software Updated design documents Updated test documents Updated user documents Test preparation review reportSystem test phase Updated software documentation Test preparation review report Updated SystemFunctional test Interface testing Test preparation review Software code listing Modification request Test documentation Test system Test reportsAcceptance test phase Test preparation review report Full integrated system Acceptance test plans Acceptance test cases Acceptance test procedures Acceptance testInter-operability testAcceptance test Acceptance test reportDelivery phase Tested/ accepted system Installation TrainingVersion description document Version description document

26

SOFTWARE MAINTENANCE MODELS

Quick-fix model. Boehms model Osbornes model Iterative enhancement model. Reuse-oriented model.

27Quick-fix Model

Identify problem & fix it as quickly as possibleNo analysis of effects is made, and there is little or no documentation to useGets work done quickly with lower costIn Quick-fix model starting point of maintenance is always source code.28Boehm's model: Economic Model

Maintenance process represented as a closed loop cycleMaintenance process is driven by the maintenance managers decisions, which are based on the balancing of objectives against the constraintsIt is the stage where management decisions are made that drives the processIn 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

29Osbornes 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 controlThe Model30Iterative Enhancement ModelIt is a three stage cycleThis model requires complete documentation as starting point of each iterationIt is similar to evolutionary development paradigmExisting documentation for each stage is: - Requirement documentation, Design Documentation, Source code documentation, & Test documentation31 Iterative Enhancement Model

32The Reuse-Oriented ModelMaintenance 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.

33Reuse-oriented Model

Component Library

34The 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, andIntegrating the modified parts into the new system.

35TECHNIQUES 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.

36Configuration 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.

37Software 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.

38Impact AnalysisImpact 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.

39Software 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.

40Redocumentation

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.

41Restructuring

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.

42Reverse EngineeringFocuses 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.

43Re-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.

44Software Maintenance Tools

NameDescription

File comparatorsCompares 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 linkersCompilers 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. DebuggingAllows to trace the logic of the program and examines the contents of the registers and memory areas.Cross-reference generatorsAssures 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 analyzersMeasures 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.45TECHNOLOGY 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.

46Software Maintenance Documentation

1.0 Scope 1.1 Application2.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 - Database2.6 Software maintenance procedures - Programming conventions - Source library maintenance procedures - Test and verification procedures

47 Types of user Documentation Associated with Software System Modified

System EvaluatorsDescription of Services Provided Functional Description Reference Manual

User ManualInstallation GuideSystemAdministratorNoviceusersExperienced usersInformation about bug fixesRelease NoteSystem Administrator GuideUsersSystem AdministratorGetting Started with the SystemHow to Install the SystemDetails of all System Facilities How to Operation and Maintain the System48 Types of User Documentation Associated with Software System Modified

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

50