Software Maintenance PDF

CHAPTER 8: SOFTWARE MAINTENANCE SHARI L. PFLEEGER JOANN M. ATLEE 4TH EDITION 2 TOPIC COVERED System Types Software Change Strategies Maintenance Team Maintenance Problems Maintenance Cost 3 SOFTWARE CHANGES Software change is unavoidable N...

CHAPTER 8: SOFTWARE MAINTENANCE SHARI L. PFLEEGER JOANN M. ATLEE 4TH EDITION 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 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 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 results Artifacts requiring consequent change Requirement analysis Requirement specification System design Architectural design specification Technical design specification Program design Program design specification Program implementation Program code Program documentation Unit testing Test plans Test scripts System testing Test plans Test scripts System delivery User documentation Operator documentation System guide Programmer’s guide Training classes  LEHMAN’S LAWS Law Description Continuing change A program that is used in a real-world environment necessarily must change or become progressively less useful in that environment. 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. Large program evolution Program evolution is a self-regulating process. System attributes such as size , time between releases and the number of reported errors is approximately invariant for each system release. Organisational stability Over a programΥs lifetime, its rate of development is approximately constant and independent of the resources devoted to system development. Conservation of Over the lifetime of a system, the incremental change in each familiarity release is approximately constant. Continuing growth The functionality offered by systems has to continually increase to maintain user satisfaction. Declining quality The quality of systems will appear to be declining unless they are adapted to changes in their operational environment. Feedback system Evolution processes incorporate multi-agent, multi-loop feedback systems and you have to treat them as feedback systems to achieve significant product improvement.  SYSTEM MAINTENANCE VS. DECLINE 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? THE NATURE OF MAINTENANCE TYPES OF MAINTENANCE Corrective: maintaining control over day-to-day functions Adaptive: maintaining control over system modifications Perfective: perfecting existing functions Preventive: preventing system performance from degrading to unacceptable levels WHO PERFORMS MAINTENANCE 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 SKILLS OF THE MAINTAINER Novice Expert Language expertise Domain expertise Comprehension strategies expertise The specific program expertise 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 MAINTENANCE TEAM RESPONSIBILITIES 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 PROBLEMS 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) CAUSES OF MAINTENANCE PROBLEMS ◼ Unstructured code ◼ Insufficient knowledge about system and domain ◼ Insufficient documentation ◼ Bad image of maintenance department MAINTENANCE COSTS 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.) DEVELOPMENT/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 80-20 rule 20% of effort in development 80% of effort in maintenance  MAINTENANCE COST FACTORS 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  FACTORS AFFECTING MAINTENANCE EFFORT 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 Q&A Thank you