Presentation on theme: "CIS 376 Bruce R. Maxim UM-Dearborn"— Presentation transcript:
1 CIS 376 Bruce R. Maxim UM-Dearborn Legacy SystemsCIS 376Bruce R. MaximUM-Dearborn
2 What are legacy systems? Systems developed for a specific client that have been in service for a long-timeMany of these systems were developed years ago using obsolete technologiesThey are likely to be business critical systems required for normal operation of a businessThese are the systems that everyone worried about when the Y2K concerns became public
3 Legacy System Replacement The business risks associated with the strategy of scrapping a legacy system and replacing it with a new one are not insignificantlegacy systems rarely have complete specificationschanges are not likely to be documented well at allbusiness processes are reliant on the systemthe legacy system may contain embedded business rules that are not formally documented elsewheresoftware development is risky and not is always successful
4 Changing Legacy Systems All systems must change to remain usefulChanges to legacy systems can be very expensivecomponents may be implemented with different programming styles as changes are implementedsystem may be written in an obsolete languagesystem documents often out-of-datesystem structure may be corrupted by years of maintenance activitiestechniques used to save space or increase speed may have obscured understandabilityfile structures used may be incompatible with each other
5 Legacy System RisksReplacing a legacy system is both expensive and riskyMaintaining a legacy system is also expensive and riskySometimes a the decision is made (based on the costs and risks involved) to extend system life-time using techniques like re-engineering
6 Socio-Technical Systems Lagacy systems are more than just software systemsSommerville describes legacy systems as socio-technical systemsSocio-Technical System Layersbusiness processesapplication softwaresupport softwarehardware
7 Legacy System Structures System Hardwarecould be a mainframeSystem SoftwareApplication SoftwareApplication Databusiness critical data often used by several programsBusiness Processesprocesses that support a business objective and rely on the legacy systems hardware and softwareBusiness Policies and Rulesbusiness operation constraints
9 System Change In theory In practice it should be possible to replace one layer in a socio-technical system without making any changes to the other layersIn practicechanging one layer introduces new facilities that must be used in higher level layerschanging the software may require hardware changes to maintain system performanceit may be impossible to maintain hardware interfaces because of the huge differences between mainframe and client-server architectures
10 Here are some architecture examples from Sommerville that indicate some of the types coupling that may be involved in among legacy systems.
14 Legacy Data ConcernsFile-based systems may have several programs accessing and modifying incompatible data filesIt would be common to move from a file-based system to a database management system (DBMS)It is possible that the DBMS itself has become obsolete and needs to be replacedThe DBMS may be incompatible with other database systems used in the businessThe teleprocessing monitor used in a transaction processing system may only work with a particular DBMS and mainframe environment
15 Legacy System DesignMost legacy systems were designed without using object-oriented techniquesA legacy system is not likely to have been designed as a set of interacting objectsA legacy system is more likely to be designed using a function-oriented design strategyMany software engineering methods and CASE tools support function-oriented designFunction-oriented design is common in MIS applications
17 Functional Design Process Dataflow Designused to model information flowStructural Decompositiondecomposition of functions into sub-functions shown using graphical structure chart that makes use of the input-process-output modelDetailed Designthe entities and their interfaces are recorded in the data dictionary and the processing detail is represented using a program design language (PDL)
19 Input-Process-Output Input Componentsread and validate data received file or deviceProcessing Componentscarry out transformations on the input dataOutput Componentsformat and display results of the data transformationsInput, process, and output can be represented as functions with data flowing between them and as a bubble in the dataflow diagram
20 Using Function-Oriented Design For some systems (e.g. transaction processing systems) a function-oriented approach may be more natural than an object-oriented approachCompanies with a heavy investment in CASE tools that support function-oriented design may not want to pay the price of moving to an object-oriented approach
21 Legacy System Assessment Companies that rely on legacy systems must have a strategy for evolving these systemsscrap the system and modify business practices so it is not neededcontinue maintaining the old systemre-engineer the old system to improve maintainabilityreplace the old system with a new systemThe strategy chosen depends on the quality of the system and its business value
22 Business Value Assessment Need to take different viewpoints into accountsystem end-usersbusiness customersbusiness managersIT managerssenior managementProcess is similar to system feasibility assessmentInterview stakeholders and collate the results
23 System Quality Assessment Business Process AssessmentHow well does the business process support the current goals of the business?Environment AssessmentHow effective is the system environment?How costly is it to maintain?Application AssessmentWhat is the quality of the application software system?
24 Business Process Assessment Interview representatives from each group of stakeholders and askIs there a defined process model and is it followed?Does everyone in the company use the same processes to achieve the same function?How has the process been adapted to meet local needs?What are the relationships between this process and other business processes?Is the process supported effectively by the legacy system?
25 Environment Assessment System software or hardware supplier stabilityHardware failure rateAge of hardware and softwarePerformance of systemSupport requirements for hardware and softwareMaintenance costsInteroperability with other business systems
26 Application Assessment Factors Understandability of source codeDocumentation qualityData model (existence and duplication)PerformanceProgramming language usedConfiguration management controlsTest data existence and regression test resultsTeam members capable of maintaining application
27 System MeasurementCollecting quantitative data can help assess the quality of the applicationnumber of system change requests madenumber of user interfaces in the systemvolume of data used by systemreliability measuresdefect detection or removal rates
29 Legacy System Categories Low quality, Low business valuescrap the systemLow quality, High business valueshould be re-engineered or replaced if a suitable system is availableHigh-quality, Low business valuereplace with COTS, scrap system, or maintainHigh-quality, High business valuecontinue operation using normal maintenance practices