Chapter 9 Software Maintenance  2004 by SEC

Chapter 9 Software Maintenance 2004 by SEC

Chapter 9 Software Maintenance 9.1 Software Evolution 9.2 Types of Software Maintenance 9.3 Maintenance Techniques 9.4 The Management of Maintenance 9.5 Qualities in Maintenance 9.6 Reengineering, Reverse Engineering and Forward Engineering Exercise 2 2004 by SEC

9.1 Software Evolution 3 2004 by SEC

Software Evolution It is impossible to produce system of any size which do not ne ed to be changed. Once software is put into use, new requirem ents emerge and existing requirements changes as the business running that software changes. Parts of the software may have to be modified to correct errors that are found in operation, improve its performance or other n on-functional characteristics. All of this means that, after delivery, software systems always evolve in response to demand for change. 4 2004 by SEC

Program Evolution Dynamic Program evolution dynamic is the study of system change. Th e majority of work in this area has been carried out by Lehm an and Belady. From these studies , they proposed a sets of la ws concerning system change. Law Description Continuing change A program that is used in 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 simplify the structure. 5 2004 by SEC

Program Evolution Dynamic (cont’d) Law Description Large program evolution Program evolution is self-regulation process. System attributes such as size, time between release and the number of report errors are approximately invariant for each system release Organizational stability Over a program’s lifetime, its rate of development is approximately constant and independent of the resources devoted to the system development Conservation of familiarity Over the lifetime of system, the incremental change in each release is approximately constant. 6 2004 by SEC

Software Evolution Approaches There are a number of different strategies for software change .[SOM2004] – Software maintenance – Architectural transformation – Software re-engineering. Software maintenance – Changes to the software are made in response to changed requirements but the fundamental structure of the software remains stable. This is m ost common approach used to system change. 7 2004 by SEC

Software Evolution Approaches (cont’d ) Architectural transformation – This is a more radical approach to software change then maintenance a s it involves making significant change to the architecture of the syste m. Software re-engineering – This is different from other strategies in that no new functionality is ad ded to the system. – System re-engineering may involve some structural modifications but dose not usually involves major architectural change. 8 2004 by SEC

9.2 Types of Software Maintenance 9 2004 by SEC

Software Maintenance Software maintenance is the general process of changing a system after it has been diverted. The change may be simple changes to correct coding errors, more extensive changes to correct design errors or significant enhancement to correct specification error or accommodate new requirements. 10 2004 by SEC

Maintenance Characteristics We need to look at maintenance from three different viewpoin ts: [PRE2004] – the activities required to accomplish the maintenance phase and the im pact of a software engineering approach (or lack thereof) on the useful ness of such activities – the costs associated with the maintenance phase – the problems that are frequently encountered when software maintenan ce is undertaken 11 2004 by SEC

Types of Maintenance Maintenance to repair software faults – Maintenance to adapt software to a different operating environment – Changing a system to correct deficiencies in the way meets its requirements Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation Maintenance to add to or modify the system’s functionality – Modifying the system to satisfy new requirements 12 2004 by SEC

Fault repair (17%) functionality addition or modification (65%) software adaption (18%) Maintenance effort distribution .[SOM2004] 13 2004 by SEC

Development vs. Maintenance not directly linked to the r directly driven by the real eal world world freedom constrained by existing sy stem defects have no immediat e effect defects disrupt production methods available system not using current methods standards may be enforce d shifting standards, if any 14 2004 by SEC

Maintenance Examples Y2K – many, many systems had to be updated – language analyzers (find where changes need to be made) Anti-Virus Software – don't usually have to update software, but must send virus definitions 15 2004 by SEC

Maintenance Examples (cont’d) Operating System Patching – Microsoft, Apple, Linux/Unix – OS is core to use of computer, so it must be constantly maintained Commercial Software in General – customers need to be informed of updates – updates have to be easily available - web is good tool 16 2004 by SEC

The Maintenance Process Maintenance process vary considerably depending on the typ es of software being maintained, the development processes u sed in an organization and people involved in the process. Change requests Impact analysis Release planning Fault repair Flat form adaptation Change implementation System release System enhancement Overview of the Maintenance Process .[SOM2004] 17 2004 by SEC

Change Requests Change requests are requests for system changes from users, customers or management In principle, all change requests should be carefully analysed as part of the maintenance process and then implemented In practice, some change requests must be implemented urgently – Fault repair – Changes to the system’s environment – Urgently required business changes 18 2004 by SEC

Change Implementation Proposed changes Requirements analysis Requirements updating Software development Change implementation. [SOM2004] 19 2004 by SEC

Emergency Repair Change requests Analyze source code Modify source code Deliver modified system Emergency repair [SOM2004] 20 2004 by SEC

Why is Maintenance Inefficient? Factors adversely effect maintenance – Lack of models or ignorance of available models (73%) – Lack of documentation (67.6%) – Lack of time to update existing documentation (54.1%) Other factors (1994 study) – Quality of original application – Documentation quality – Rotation of maintenance people 21 2004 by SEC

Why is Maintenance Inefficient? (cont’d) More factors (Yip ’95 study) – Lack of human resources – Different programming styles conflict – Lack of documentation and tools – Bad maintenance management – Documentation policy – Turnover 22 2004 by SEC

9.3 Maintenance Techniques 23 2004 by SEC

Architectural Evolution There is a need to convert many legacy systems from a centralised architecture to a client-server architecture Change drivers – Hardware costs. Servers are cheaper than mainframes – User interface expectations. Users expect graphical user interfaces – Distributed access to systems. Users wish to access the system from different, geographically separated, computers 24 2004 by SEC

Distribution Factors [SOM2004] Factor Business importance System age System structure Hardware procurement policies Description Returns on the investment of distributing a legacy system depend on its importance to the business and how long it will remain important. If distribution provides more efficient support for stable business processes then it is more likely to be a cost-effective evolution strategy. The older the system the more difficult it will be to modify its architecture because previous changes will have degraded the structure of the system. The more modular the system, the easier it will be to change the architecture. If the application logic, the data management and the user interface of the system are closely intertwined, it will be difficult to separate functions for migration. Application distribution may be necessary if there is company policy to replace expensive mainframe computers with cheaper servers. . 25 2004 by SEC

Legacy System Structure Ideally, for distribution, there should be a clear separation between the user interface, the system services and the system data management In practice, these are usually intermingled in older legacy systems 26 2004 by SEC

Legacy System Structures [SOM2004] User interface Services Database Ideal model for distribution User interface Services Database Real legacy systems 27 2004 by SEC

Layered Distribution Model [SOM2004] Presentation Data validation Interaction control Application services Database 28 2004 by SEC

Legacy System Distribution [SOM2004] Desktop PC clients running application Legacy system Application services Database Middleware layer (wrapper) User interface Legacy system Character terminals 29 2004 by SEC

Distribution Options The more that is distributed from the server to the client, the higher the costs of architectural evolution The simplest distribution model is UI distribution where only the user interface is implemented on the server The most complex option is where the server simply provides data management and application services are implemented on the client 30 2004 by SEC

Distribution Option Spectrum [SOM2004] Server: Interaction control Data validation Services Database Server: Services Database Server:Database Client: Presentation Client: Presentation Interaction control Data validation Client: Presentation Interaction control Data validation Services Increasing cost and effort 31 2004 by SEC

User Interface Distribution UI distribution takes advantage of the local processing power on PCs to implement a graphical user interface Where there is a clear separation between the UI and the application then the legacy system can be modified to distribute the UI Otherwise, screen management middleware can translate text interfaces to graphical interfaces 32 2004 by SEC

User Interface Distribution [SOM2004] Screen descriptions Desktop PC clients with GUI interface Legacy system Application services Database Screen management middleware User interface 33 2004 by SEC

UI Migration Strategies [SOM2004] 34 2004 by SEC

9.4 The Management of Maintenance 35 2004 by SEC

Model of Maintenance Effort Model of maintenance effort M p K (c-d) [PRE2004] M total maintenance effort over entire lifecycle p productive efforts: analysis, design, code, test c complexity due to lack of structured design and documentation d degree of familiarization with the system K empirically determined constant 36 2004 by SEC

Model of Maintenance Effort (cont’d) Model of maintenance effort M p K (c-d) Cost of maintenance increases exponentially. Costs are reduced by structured development Costs are reduced by giving the maintenance team time to become thorou ghly familiar with the system 37 2004 by SEC

What Affects the Maintainability of an Application? Application age – (software rust?) older programs were probably worse written and have probably been patched more Size – measured in KLOC, number of input/output files Programming language – 4gls are supposed to produce more maintainable code than 3gls 38 2004 by SEC

What Affects the Maintainability of an Application? (cont’d) Processing environment – files harder to maintain than databases, real-time harder than batch Analysis and design methodologies – well designed software is supposed to be much easier to maintain Structured programming – there is conflicting evidence whether this really helps 39 2004 by SEC

What Affects the Maintainability of an Application? (cont’d) Modularization – (central thesis of all the oo techniques) small reasonably self contained pieces of code should be easier to maintain Documentation generation – maintenance of documentation is as expensive as maintenance of code End-user involvement – some researchers believe when end users are more involved maintenan ce decreases 40 2004 by SEC

What Affects the Maintainability of an Application? (cont’d) Maintenance management – scheduling and the attitudes of management to affects productivity 41 2004 by SEC

Problems in Managing Maintenance Changing priorities – chaotic nature of maintenance requests, the length of maintenance task s causing new requests to come along before an ongoing task is done. Inadequate testing methods – lack of time set aside for testing, of comprehensive test data, of rigorou s testing requirements as a standard for signing off. Performance measurement difficulties – how do you measure individual or group performance? System documentation incomplete or non-existent – training takes a long time for learning an application so programmers g et stuck on one piece of software. Adapting to the rapidly changing business environment – hardware and software also become obsolete. 42 2004 by SEC

Problems in Managing Maintenance (co nt’d) From survey of 60 US & Canadian companies in Software Ma intenance News 1992 – These are the consequence of the lack of mature tools and techniques f or software maintenance and its management. – We need predictive models of maintenance to estimate how much effor t needs to go into it. – By and large maintainers work in isolation and are not closely manage d. Each one has to learn from personal experience good methods of wo rking. 43 2004 by SEC

Maintenance Prediction Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs – Change acceptance depends on the maintainability of the components affected by the change – Implementing changes degrades the system and reduces its maintainability – Maintenance costs depend on the number of changes and costs of change depend on maintainability 44 2004 by SEC

Maintenance Prediction (cont’d) Predicting the number of changes requires and understanding of the relationships between a system and its environment Tightly coupled systems require changes whenever the environment is changed Factors influencing this relationship are – Number and complexity of system interfaces – Number of inherently volatile system requirements – The business processes where the system is used 45 2004 by SEC

Maintenance Prediction (cont’d) Predictions of maintainability can be made by assessing the complexity of system components Studies have shown that most maintenance effort is spent on a relatively small number of system components Complexity depends on – Complexity of control structures – Complexity of data structures – Procedure and module size 46 2004 by SEC

Maintenance Prediction (cont’d) Process measurements may be used to assess maintainability – Number of requests for corrective maintenance – Average time required for impact analysis – Average time taken to implement a change request – Number of outstanding change requests If any or all of these is increasing, this may indicate a decline in maintainability 47 2004 by SEC

Maintenance Costs Usually greater than development costs (2* to 100* depending on the application) 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.) 48 2004 by SEC

Maintenance Costs (cont’d) Time and money (software that costs 10 a line to develop costs 400 a li ne to maintain) Organizations become maintenance bound and cannot produce new softw are Customer dissatisfaction when seemingly legitimate requests for repair or modification cannot be addressed in a timely manner Reduction in overall software quality as changes introduce latent errors in the maintained software Upheaval caused during development efforts when staff must be “pulled” t o work on a maintenance task 49 2004 by SEC

Development/Maintenance Costs [SOM2004] System 1 System 2 0 50 100 150 Development costs 200 250 300 350 400 450 500 Maintenance costs 50 2004 by SEC

Maintenance Cost Factors Team stability – 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 costs are reduced if the same staff are involved with them for some time 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 51 2004 by SEC

Change Management Change is a fact of life for large software. A defined change management process and associated CASE tools ensure that t hese changes are recorded and applied to the system in a costeffective way. The change management process should come into effect whe n the software associated document is put under the control of the configuration management team. Change management procedures should be designed to ensure that the costs and benefits of change are properly analyzed an d changes to a system are made in a controlled way. 52 2004 by SEC

Change Management Process Request change by completing a change request form Analyze change request If change is valid then { Assess how change might be implemented Assess change cost Record change request in database Submit request to change control board 53 2004 by SEC

Change Management Process (cont’d) If change is accepted then{ Repeat{ make changes to software record changes and link to associated change request submit changed software for quality approval} Until{ software quality is adequate create new system version}} else {reject change request}} 54 2004 by SEC

Change Request Form [SOM2004] Project: Proteus/PCL-Tools Change requester: I.Sommerville Number: 23/94 Date: 1/9/98 Requested change: when a component is selected from the structure, display the name of the file where it is stored. Change analyzer: G.Dean analysis Date:10/9/98 Components affected: Display-icon.Select, Display-icon.Display Associated component: File Table Change assessment: Relatively simple to implement as a file name table is available. Requires th e design and implementation of a display field. No changes to associated components are required . Change priority: Low Change implementation: Estimated effort: 0.5 days Date to CCB: 15/9/98 CCB decision date: 1/11/98 Change implementor: Date of change: Date submitted to QA: QA decision: Date submitted to CM: comments CCB- change control board 55 2004 by SEC

9.5 Qualities in Maintenance 56 2004 by SEC

Maintenance Side Effects In this context a side effect implies an error or undesirable be havior that occurs as the result of a modification. the three major areas are[PRE2004] – code – data structures – documentation 57 2004 by SEC

Documentation Side Effects These consist of the failure to update documentation so that it no longer matches the code. If the user doesn’t know about changes frustration is inevitabl e. The entire documentation should be reviewed before re-releas e 58 2004 by SEC

Coding Side Effects Any change can cause side-effects but these tend to be more error prone a subprogram is deleted or changed A statement label is deleted or modified An identifier is deleted or modified Changes are made to improve execution performance 59 2004 by SEC

Coding Side Effects (cont’d) Logical operators are modified Files are opened or closed Design changes which translate into major code changes Changes are made to logical tests of boundary conditions These may be caught in testing or cause software failure durin g operation. 60 2004 by SEC

Data Side Effects Data side effects occur as the result of modifications made to a data structure. The most error-prone are: – redefinition of local and global constants – redefinition of record or file formats – Incr. or decr. in size of array or other data structure – modification of global data – re initialization of control flags and pointers – rearrangements of parameters (especially in I/O) 61 2004 by SEC

9.6 Re-engineering, Reverse Engineerin g and Forward Engineering, 62 2004 by SEC

Software Rejuvenation Re-documentation – Creation or revision of alternative representations of software at the same level of abstraction – Generates: data interface tables, call graphs, component/variable cross references etc. Restructuring – transformation of the system’s code without changing its behavior 63 2004 by SEC

Software Rejuvenation (cont’d) Reverse Engineering – Analyzing a system to extract information about the behavior and/or st ructure also Design Recovery - recreation of design abstractions from cod e, documentation, and domain knowledge – Generates: structure charts, entity relationship diagrams, DFDs, requirements models Re-engineering – Examination and alteration of a system to reconstitute it in another for m – Also known as renovation, reclamation 64 2004 by SEC

System Re-engineering Re-structuring or re-writing part or all of a legacy system without changing its functionality Applicable where some but not all sub-systems of a larger system require frequent maintenance Re-engineering involves adding effort to make them easier to maintain. The system may be re-structured and re-documented 65 2004 by SEC

When to Re-engineer When system changes are mostly confined to part of the system then re-engineer that part When hardware or software support becomes obsolete When tools to support re-structuring are available 66 2004 by SEC

Re-engineering Advantages Reduced risk – There is a high risk in new software development. There may be development problems, staffing problems and specification problems Reduced cost – The cost of re-engineering is often significantly less than the costs of developing new software 67 2004 by SEC

Forward Engineering and Reengineering [SOM2004] System specification Design and implementation Ne w system Understanding and transformation Re-engineered system Forward engineering Existing software system Software re-engineering 68 2004 by SEC

The Re-engineering Process [SOM2004] Program documentation Original program Modularised program Original data Reverse engineering Program modularisation Source code translation Data reengineering Program structure improvement Structured program Reengineered data 69 2004 by SEC

Re-Engineering Cost Factors The quality of the software to be re-engineered The tool support available for re-engineering The extent of the data conversion which is required The availability of expert staff for re-engineering 70 2004 by SEC

Re-Engineering Approaches [SOM2004] Automated progr am restructuring Automated source code conversion Program and data restructuring Automated r estructuring with manual changes Restructuring plus architectural changes Increased cost 71 2004 by SEC

Source Code Translation Involves converting the code from one language (or language version) to another e.g. FORTRAN to C May be necessary because of: – Hardware platform update – Staff skill shortages – Organisational policy changes Only realistic if an automatic translator is available 72 2004 by SEC

The Program Translation Process [SOM2004] System to be re-engineered Identify source code differences Design translator instructions System to be re-engineered Re-engineered system Automatically transla te code Manually transla te code 73 2004 by SEC

Program Structure Improvement Maintenance tends to corrupt the structure of a program. It becomes harder and harder to understand The program may be automatically restructured to remove unconditional branches Conditions may be simplified to make them more readable 74 2004 by SEC

Spaghetti Logic [SOM2004] 75 2004 by SEC

Structured Control Logic [SOM2004] 76 2004 by SEC

Condition Simplification -- Complex condition if not (A B and (C D or not ( E F) ) ). -- Simplified condition if (A B and (C D or E F). 77 2004 by SEC

Automatic Program Restructuring [SOM2004] Program to be restructured Restructur ed program Analyser and graph builder Program generator Graph repr esentation 78 2004 by SEC

Restructuring Problems Problems with re-structuring are: – Loss of comments – Loss of documentation – Heavy computational demands Restructuring doesn’t help with poor modularisation where related components are dispersed throughout the code The understandability of data-driven programs may not be improved by re-structuring 79 2004 by SEC

Module types Data abstractions – Hardware modules – All functions required to interface with a hardware unit Functional modules – Abstract data types where data structures and associated operations are grouped Modules containing functions that carry out closely related tasks Process support modules – Modules where the functions support a business process or process fragment 80 2004 by SEC

Recovering Data Abstractions Many legacy systems use shared tables and global data to save memory space Causes problems because changes have a wide impact in the system Shared global data may be converted to objects or ADTs – Analyse common data areas to identify logical abstractions – Create an ADT or object for these abstractions – Use a browser to find all data references and replace with reference to the data abstraction 81 2004 by SEC

Data Abstraction Recovery Analyse common data areas to identify logical abstractions Create an abstract data type or object class for each of these abstractions Provide functions to access and update each field of the data abstraction Use a program browser to find calls to these data abstractions and replace these with the new defined functions 82 2004 by SEC

Data Re-engineering Involves analysing and reorganising the data structures (and sometimes the data values) in a program May be part of the process of migrating from a file-based system to a DBMS-based system or changing from one DBMS to another Objective is to create a managed data environment 83 2004 by SEC

Approaches to Data Re-engineering [SOM2004] Approach Data cleanup Data extension Data migration Description The data records and values are analysed to improve their quality. Duplicates are removed, redundant information is deleted and a consistent format applied to all records. This should not normally require any associated program changes. In this case, the data and associated programs are re-engineered to remove limits on the data processing. This may require changes to programs to increase field lengths, modify upper limits on the tables, etc. The data itself may then have to be rewritten and cleaned up to reflect the program changes. In this case, data is moved into the control of a modern database management system. The data may be stored in separate files or may be managed by an older type of DBMS. 84 2004 by SEC

Data Problems End-users want data on their desktop machines rather than in a file system. They need to be able to download this data from a DBMS Systems may have to process much more data than was originally intended by their designers Redundant data may be stored in different formats in different places in the system 85 2004 by SEC

Data Problems (cont’d) Data naming problems – Field length problems – Names may be hard to understand. The same data may have different names in different programs The same item may be assigned different lengths in different programs Record organisation problems – Records representing the same entity may be organised differently in different programs Hard-coded literals No data dictionary 86 2004 by SEC

Data Conversion Data re-engineering may involve changing the data structure organisation without changing the data values Data value conversion is very expensive. Special-purpose programs have to be written to carry out the conversion 87 2004 by SEC

The Data Re-engineering Process [SOM2004] Data analysis Program to be re-engineered Data analysis Entity name modification Literal replacement Data definition re-ordering Stage 1 Data re-formatting Default value conversion Validation rule modification Stage 2 Change summary tables Data conversion Stage 3 Modified data 88 2004 by SEC

Reverse Engineering Analysing software with a view to understanding its design and specification May be part of a re-engineering process but may also be used to re-specify a system for re-implementation Builds a program data base and generates information from this Program understanding tools (browsers, cross-reference generators, etc.) may be used in this process 89 2004 by SEC

The Reverse Engineering Process [SOM2004] Program stucture diagrams Automated analysis System information store System to be re-engineered Manual annotation Document generation Data stucture diagrams Traceability matrices 90 2004 by SEC

References [PRE2004] Roger S. Pressman. Software Engineering: a practitioner’s app roach, 6th edition. McGRAW-HILL, 2004. [SOM2004] Ian Sommerville. Software Engineering, 7th edition. Addison Wesley, 2004 91 2004 by SEC