1. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 1 Legacy Systems l Older software systems that remain vital to an organisation

2. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 2 Legacy systems l Software systems that are developed specially for an organisation have a long lifetime l Many software systems that are still in use were developed many years ago using technologies that are now obsolete l These systems are still business critical that is, they are essential for the normal functioning of the business l They have been given the name legacy systems

3. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 3 Legacy system replacement l There is a significant business risk in simply scrapping a legacy system and replacing it with a system that has been developed using modern technology –Legacy systems rarely have a complete specification. During their lifetime they have undergone major changes which may not have been documented –Business processes are reliant on the legacy system –The system may embed business rules that are not formally documented elsewhere –New software development is risky and may not be successful

4. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 4 Legacy system change l Systems must change in order to remain useful l However, changing legacy systems is often expensive –Different parts implemented by different teams so no consistent programming style –The system may use an obsolete programming language –The system documentation is often out-of-date –The system structure may be corrupted by many years of maintenance –Techniques to save space or increase speed at the expense of understandability may have been used –File structures used may be incompatible

5. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 5 The legacy dilemma l It is expensive and risky to replace the legacy system l It is expensive to maintain the legacy system l Businesses must weigh up the costs and risks and may choose to extend the system lifetime using techniques such as re-engineering. l This is covered in Chapters 27 and 28

6. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 6 Legacy system structures l Legacy systems can be considered to be socio- technical systems and not simply software systems –System hardware - may be mainframe hardware –Support software - operating systems and utilities –Application software - several different programs –Application data - data used by these programs that is often critical business information –Business processes - the processes that support a business objective and which rely on the legacy software and hardware –Business policies and rules - constraints on business operations

7. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 7 Legacy system components

8. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 8 Layered model

9. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 9 System change l In principle, it should be possible to replace a layer in the system leaving the other layers unchanged l In practice, this is usually impossible –Changing one layer introduces new facilities and higher level layers must then change to make use of these –Changing the software may slow it down so hardware changes are then required –It is often impossible to maintain hardware interfaces because of the wide gap between mainframes and client-server systems

10. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 10 Legacy application system

11. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 11 Database-centred system

12. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 12 Transaction processing

13. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 13 Legacy data l The system may be file-based with incompatible files. The change required may be to move to a database-management system l In legacy systems that use a DBMS the database management system may be obsolete and incompatible with other DBMSs used by the business l The teleprocessing monitor may be designed for a particular DB and mainframe. Changing to a new DB may require a new TP monitor

14. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 14 Legacy system design l Most legacy systems were designed before object-oriented development was used l Rather than being organised as a set of interacting objects, these systems have been designed using a function-oriented design strategy l Several methods and CASE tools are available to support function-oriented design and the approach is still used for many business applications

15. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 15 Legacy system assessment l Organisations that rely on legacy systems must choose a strategy for evolving these systems –Scrap the system completely and modify business processes so that it is no longer required –Continue maintaining the system –Transform the system by re-engineering to improve its maintainability –Replace the system with a new system l The strategy chosen should depend on the system quality and its business value

16. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 16 System quality and business value

17. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 17 Legacy system categories l Low quality, low business value –These systems should be scrapped l Low-quality, high-business value –These make an important business contribution but are expensive to maintain. Should be re-engineered or replaced if a suitable system is available l High-quality, low-business value –Replace with COTS, scrap completely or maintain l High-quality, high business value –Continue in operation using normal system maintenance

18. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 18 Business value assessment l Assessment should take different viewpoints into account –System end-users –Business customers –Line managers –IT managers –Senior managers l Interview different stakeholders and collate results

19. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 19 System quality assessment l Business process assessment –How well does the business process support the current goals of the business? l Environment assessment –How effective is the system’s environment and how expensive is it to maintain l Application assessment –What is the quality of the application software system

20. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 20 Business process assessment l Use a viewpoint-oriented approach and seek answers from system stakeholders –Is there a defined process model and is it followed? –Do different parts of the organisation use different processes for the same function? –How has the process been adapted? –What are the relationships with other business processes and are these necessary? –Is the process effectively supported by the legacy application software?

21. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 21 Environment assessment

22. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 22 Application assessment

23. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 23 System measurement l You may collect quantitative data to make an assessment of the quality of the application system –The number of system change requests –The number of different user interfaces used by the system –The volume of data used by the system

24. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 24 Software maintenance l Managing the processes of system change

25. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 25 l Modifying a program after it has been put into use l Maintenance management is concerned with planning and predicting the process of change l Configuration management is the management of products undergoing change. Covered in the following chapter Software maintenance

26. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 26 l The system requirements are likely to change while the system is being developed because the environment is changing. Therefore a delivered system won't meet its requirements! l Systems are tightly coupled with their environment. When a system is installed in an environment it changes that environment and therefore changes the system requirements. l Systems MUST be maintained therefore if they are to remain useful in an environment Maintenance is inevitable

27. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 27 l Perfective maintenance –Changing a system to make it meet its requirements more effectively l Adaptive maintenance –Changing a system to meet new requirements l Corrective maintenance –Changing a system to correct deficiencies in the way meets its requirements Types of maintenance

28. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 28 Distribution of maintenance effort

29. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 29 Evolving systems l It is usually more expensive to add functionality after a system has been developed rather than design this into the system –Maintenance staff are often inexperienced and unfamiliar with the application domain –Programs may be poorly structured and hard to understand –Changes may introduce new faults as the complexity of the system makes impact assessment difficult –The structure may be degraded due to continual change –There may be no documentation available to describe the program

30. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 30 l Maintenance has a poor image amongst development staff as it is not seen as challenging and creative l Maintenance costs increase as the software is maintained l The amount of software which has to be maintained increases with time l Inadequate configuration management often means that the different representations of a system are out of step Maintenance management

31. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 31 l Relate software development to organizational goals - maintenance rationale l Relate rewards to organizational performance l Integrate maintenance with development l Create a discretionary preventative maintenance budget l Plan for maintenance early in the development process l Plan to expend effort on program maintainability Staff motivation

32. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 32 The maintenance process l Maintenance is triggered by change requests from customers or marketing requirements l Changes are normally batched and implemented in a new release of the system l Programs sometimes need to be repaired without a complete process iteration but this is dangerous as it leads to documentation and programs getting out of step

33. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 33 The maintenance process

34. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 34 Change processes Fault repair process Iterative development process

35. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 35 System documentation l Requirements document l System architecture description l Program design documentation l Source code listings l Test plans and validation reports l System maintenance guide

36. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 36 Document production l Structure documents with overviews leading the reader into more detailed technical descriptions l Produce good quality, readable manuals - they may have to last 20 years l Use tool-generated documentation whenever possible

37. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 37 l Program evolution dynamics is the study of the processes of system change l After major empirical study, Lehman and Belady proposed that there were a number of ‘laws’ which applied to all systems as they evolved l 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

38. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 38 Lehman’s laws

39. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 39 l Usually greater than development costs (2* to 100* depending on the application) l Affected by both technical and non-technical factors l Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult. l Ageing software can have high support costs (e.g. old languages, compilers etc.) Maintenance costs

40. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 40 Development/maintenance costs

41. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 41 l Module independence –It should be possible to change one module without affecting others l Programming language –High-level language programs are easier to maintain l Programming style –Well-structured programs are easier to maintain l Program validation and testing –Well-validated programs tend to require fewer changes due to corrective maintenance Maintenance cost factors

42. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 42 l Documentation –Good documentation makes programs easier to understand l Configuration management –Good CM means that links between programs and their documentation are maintained l Application domain –Maintenance is easier in mature and well-understood application domains l Staff stability –Maintenance costs are reduced if the same staff are involved with them for some time Maintenance cost factors

43. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 43 Maintenance cost factors l Program age –The older the program, the more expensive it is to maintain (usually) l External environment –If a program is dependent on its external environment, it may have to be changed to reflect environmental changes l Hardware stability –Programs designed for stable hardware will not require to change as the hardware changes

44. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 44 l Measurements of program characteristics which would allow maintainability to be predicted l Essentially technical, how can technical factors above be quantified l Any software components whose measurements are out of line with other components may be excessively expensive to maintain. Perhaps perfective maintenance effort should be devoted to these components Maintenance metrics

45. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 45 l Control complexity Can be measured by examining the conditional statements in the program l Data complexity Complexity of data structures and component interfaces. l Length of identifier names Longer names imply readability l Program comments Perhaps more comments mean easier maintenance Maintenance metrics

46. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 46 l Coupling How much use is made of other components or data structures l Degree of user interaction The more user I/O, the more likely the component is to require change l Speed and space requirements Require tricky programming, harder to maintain Maintenance metrics

47. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 47 Process metrics l Number of requests for corrective maintenance l Average time required for impact analysis l Average time taken to implement a change request l Number of outstanding change requests l If any or all of these is increasing, this may indicate a decline in maintainability

48. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 48 l Log maintenance effort on a per component basis l Choose set of possible metrics which may be related to maintenance l Assess possible metrics for each maintained components l Look for correlation between maintenance effort and metric values Maintenance metrics

49. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 49 Software re-engineering l Reorganising and modifying existing software systems to make them more maintainable

50. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 50 l Re-structuring or re-writing part or all of a legacy system without changing its functionality l Applicable where some but not all sub-systems of a larger system require frequent maintenance l Re-engineering involves adding effort to make them easier to maintain. The system may be re- structured and re-documented System re-engineering

51. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 51 l When system changes are mostly confined to part of the system then re-engineer that part l When hardware or software support becomes obsolete l When tools to support re-structuring are available When to re-engineer

52. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 52 Re-engineering advantages l Reduced risk –There is a high risk in new software development. There may be development problems, staffing problems and specification problems l Reduced cost –The cost of re-engineering is often significantly less than the costs of developing new software

53. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 53 Business process re-engineering l Concerned with re-designing business processes to make them more responsive and more efficient l Often reliant on the introduction of new computer systems to support the revised processes l May force software re-engineering as the legacy systems are designed to support existing processes

54. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 54 Forward engineering and re-engineering

55. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 55 The re-engineering process

56. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 56 Re-engineering cost factors l The quality of the software to be re-engineered l The tool support available for re-engineering l The extent of the data conversion which is required l The availability of expert staff for re-engineering

57. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 57 Re-engineering approaches

58. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 58 Source code translation l Involves converting the code from one language (or language version) to another e.g. FORTRAN to C l May be necessary because of: –Hardware platform update –Staff skill shortages –Organisational policy changes l Only realistic if an automatic translator is available

59. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 59 The program translation process

60. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 60 Reverse engineering l Analysing software with a view to understanding its design and specification l May be part of a re-engineering process but may also be used to re-specify a system for re-implementation l Builds a program data base and generates information from this l Program understanding tools (browsers, cross-reference generators, etc.) may be used in this process

61. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 61 The reverse engineering process

62. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 62 Reverse engineering l Reverse engineering often precedes re- engineering but is sometimes worthwhile in its own right –The design and specification of a system may be reverse engineered so that they can be an input to the requirements specification process for the system’s replacement –The design and specification may be reverse engineered to support program maintenance

63. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 63 Program structure improvement l Maintenance tends to corrupt the structure of a program. It becomes harder and harder to understand l The program may be automatically restructured to remove unconditional branches l Conditions may be simplified to make them more readable

64. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 64 Spaghetti logic

65. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 65 Structured control logic

66. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 66 Condition simplification -- Complex condition if not (A > B and (C F) ) )... -- Simplified condition if (A = D or E > F)...

67. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 67 Automatic program restructuring

68. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 68 Restructuring problems l Problems with re-structuring are: –Loss of comments –Loss of documentation –Heavy computational demands l Restructuring doesn’t help with poor modularisation where related components are dispersed throughout the code l The understandability of data-driven programs may not be improved by re-structuring

69. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 69 Program modularisation l The process of re-organising a program so that related program parts are collected together in a single module l Usually a manual process that is carried out by program inspection and re-organisation

70. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 70 Module types l Data abstractions –Abstract data types where datastructures and associated operations are grouped l Hardware modules –All functions required to interface with a hardware unit l Functional modules –Modules containing functions that carry out closely related tasks l Process support modules –Modules where the functions support a business process or process fragment

71. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 71 Recovering data abstractions l Many legacy systems use shared tables and global data to save memory space l Causes problems because changes have a wide impact in the system l 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

72. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 72 Data abstraction recovery l Analyse common data areas to identify logical abstractions l Create an abstract data type or object class for each of these abstractions l Provide functions to access and update each field of the data abstraction l Use a program browser to find calls to these data abstractions and replace these with the new defined functions

73. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 73 Data re-engineering l Involves analysing and reorganising the data structures (and sometimes the data values) in a program l 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 l Objective is to create a managed data environment

74. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 74 Approaches to data re-engineering

75. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 75 Data problems l 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 l Systems may have to process much more data than was originally intended by their designers l Redundant data may be stored in different formats in different places in the system

76. Data migration

77. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 77 Data problems l Data naming problems –Names may be hard to understand. The same data may have different names in different programs l Field length problems –The same item may be assigned different lengths in different programs l Record organisation problems –Records representing the same entity may be organised differently in different programs l Hard-coded literals l No data dictionary

78. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 78 Data value inconsistencies

79. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 79 Data conversion l Data re-engineering may involve changing the data structure organisation without changing the data values l Data value conversion is very expensive. Special- purpose programs have to be written to carry out the conversion

80. ©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 80 The data re-engineering process