Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville

2 Topic Covered System Types Software Change Strategies Maintenance Team Maintenance Problems Maintenance Cost

3 Software Changes Software change is unavoidable  New requirements emerge when the software is used  The business environment changes  Errors must be repaired  New equipment must be accommodated  The performance or reliability may have to be improved A key problem for organisations is implementing and managing change to their legacy systems

4 Software Change Strategies Software Maintenance  Changes are made in response to changed requirements but the fundamental software structure is stable Maintenance does not normally involve major changes to the system’s architecture Software Re-engineering  No new functionality is added to the system but it is restructured and reorganised to facilitate future changes Architectural Transformation  The architecture of the system is modified generally from a centralised architecture to a distributed architecture These strategies may be applied separately or together

Program evolution dynamics: the empirical study of the process of system changes After major empirical studies:  Lehman and Belady proposed that there were a number of ‘laws’ which applied to all systems as they evolved There are sensible observations rather than laws. They are applicable to large systems developed by large organisations.  Perhaps less applicable in other cases Program Evolution Dynamics

6 Lehman’s System Types S-system: formally defined, derivable from a specification  Matrix manipulation P-system: requirements based on approximate solution to a problem, but real-world remains stable  Games (e.g., Chess) program E-system: embedded in the real world and changes as the world does  Software to predict how economy functions (but economy is not completely understood)

7 Changes During the System Life Cycle S-system: un-changed P-system: incremental change  An approximate solution  Changes as discrepancies and omissions are identified E-system: constant change

Examples of Change During Software Development Activity from which Initial change resultsArtifacts requiring consequent change Requirement analysisRequirement specification System designArchitectural design specification Technical design specification Program designProgram design specification Program implementationProgram code Program documentation Unit testingTest plans Test scripts System testingTest plans Test scripts System deliveryUser documentation Operator documentation System guide Programmer’s guide Training classes

Lehman’s Laws

Is the cost of maintenance too high? Is the system reliability unacceptable? Can the system no longer adapt to further change, and within a reasonable amount of time? Is system performance still beyond prescribed constraints? Are system functions of limited usefulness? Can other systems do the same job better, faster or cheaper? Is the cost of maintaining the hardware great enough to justify replacing it with cheaper, newer hardware? System Maintenance vs. Decline

Separate maintenance team  May be more objective  May find it easier to distinguish how a system should work from how it does work Part of development team  Will build the system in a way that makes maintenance easier  Problem: May feel over confident, and ignore the documentation to help maintenance effort Who Performs Maintenance

Novice Expert  Language expertise  Domain expertise  Comprehension strategies expertise  The specific program expertise Skills of The Maintainer

Information Needs Domain expert’s view  Concepts of the domain and their relations  Scope and boundaries of the program  Goals of the program User’s view  Constraints Size Timing  Operations of the program  Installation

Information Needs Programmer’s view  Dependency graph  Program parts (classes, functions) and their dependencies (call, use inheritance)  Algorithms: How are the goals accomplished?  Representations: How are entities and relations of the domain reflected in the program?  Resource allocation: Memory size, timing

Information Sources Programmer’s knowledge Code Documentation Colleagues on the project

Program Comprehension: Understanding the system Traceability: Locating information in system documentation Perform the required changes  Extending existing functions to accommodate new or changing requirements  Adding new functions to the system  Finding the source of system failures or problems  Locating and correcting faults  Restructuring design and code components  Rewriting design and code components  Deleting design and code components that are no longer useful Maintenance Team Responsibilities

Keeping system documentation up-to-date Answering questions about the way the modified system works Maintenance Team Responsibilities

Staff Problems  Limited understanding (47% of effort is spent on understanding)  Management priorities: rushing a new product to the market  Morale: “second-hand” status accorded to maintenance team Technical Problems  Artifacts and paradigms (e.g., legacy, non-OO)  Testing difficulties (some systems must be available around a clock) Maintenance Problems

Unstructured code Insufficient knowledge about system and domain Insufficient documentation Bad image of maintenance department Causes of Maintenance Problems

Usually greater than development costs Affected by both technical and non-technical factors Increases as software is maintained.  Maintenance corrupts the software structure so makes further maintenance more difficult. Ageing software can have high support costs (e.g. old languages, compilers etc.) Maintenance Costs

Development/Maintenance Costs

Parikh and Zvegintzov (1983)  Development time: 2 years  Maintenance time: 5 to 6 years Fjedstad and Hamlen (1979)  39% of effort in development  61% of effort in maintenance rule  20% of effort in development  80% of effort in maintenance Development/Maintenance Costs

Team stability  Maintenance costs are reduced if the same staff are involved with them for some time Contractual responsibility  The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change Staff skills  Maintenance staff are often inexperienced and have limited domain knowledge Program age and structure  As programs age, their structure is degraded and they become harder to understand and change Maintenance Cost Factors

Application type System novelty Turnover and maintenance staff ability System life span Dependence on a changing environment Hardware characteristics Design quality Code quality Documentation quality Testing quality Factors Affecting Maintenance Effort