System Implementation 1 Software and Hardware Acquisition w

  • Slides: 82
Download presentation
System Implementation 1

System Implementation 1

Software and Hardware Acquisition w Recognize Need, Appoint Committee and/or Project Manager: For large

Software and Hardware Acquisition w Recognize Need, Appoint Committee and/or Project Manager: For large systems, the majority of the appointed committee members should be users from functional areas and end users, joined by information technology staff. Throughout the process committee members should represent their constituencies. 2

w It should inform and seek advice and input from a broad spectrum of

w It should inform and seek advice and input from a broad spectrum of users, and from specialists such as technical support staff, Procurement, and legal staff. The committee as a whole should represent the entire business committee to be affected by the software. 3

Software and Hardware Acquisition cont… w Define Procurement Process: This document is comprised of

Software and Hardware Acquisition cont… w Define Procurement Process: This document is comprised of policy, practices, principles, and recommended procedures. How these apply to a specific software or hardware acquisition should be addressed with Procurement. 4

Software and Hardware Acquisition cont… w Define General Needs and Develop Budget Projection: General

Software and Hardware Acquisition cont… w Define General Needs and Develop Budget Projection: General needs should be identified based on the problems to be solved as well as what could reasonably be expected to be available in the marketplace. Care should be taken to avoid defining needs too narrowly too early in the process. Preliminary budget projections may cover only the cost of hardware/software and a general estimate of other expenses. 5

Software and Hardware Acquisition cont… w Investigate the Market: Investigating the market may involve

Software and Hardware Acquisition cont… w Investigate the Market: Investigating the market may involve site visits, communication with other institutions using the product, vendor demonstrations, or a Request for Information (RFI). A broad base of potential vendors should be given an opportunity to participate. 6

Software and Hardware Acquisition cont… w Refine the Budget and Identify a Funding Plan:

Software and Hardware Acquisition cont… w Refine the Budget and Identify a Funding Plan: Before proceeding with the project, a refined budget plan should be prepared which covers all costs of consulting, acquisition, licensing, hardware, additional staffing, implementation, testing, training, maintenance, and upgrades, for a three to five year period. 7

w Consideration should also be given to costs of integration with existing systems, and

w Consideration should also be given to costs of integration with existing systems, and to savings which may be obtained from phasing out systems that are no longer needed. Identify funding sources and obtain appropriate approvals. 8

Software and Hardware Acquisition cont… w Define Detailed Needs: A thorough needs analysis of

Software and Hardware Acquisition cont… w Define Detailed Needs: A thorough needs analysis of software capabilities should be conducted. For example, for a Human Resources system, this analysis should encompass the needs of functional staff (such as Human Resources), end users (such as general departmental users), and technical staff (such as IT staff responsible for maintaining the system). 9

Software and Hardware Acquisition cont… w The analysis should distinguish between required and desired

Software and Hardware Acquisition cont… w The analysis should distinguish between required and desired capabilities and should also cover such things as maintenance, support, training, upgrades, existing or proposed hardware, and the computing infrastructure. If necessary, the budget plan should be revised. 10

Software and Hardware Acquisition cont… w Prepare and Issue an Request for Procurement (RFP):

Software and Hardware Acquisition cont… w Prepare and Issue an Request for Procurement (RFP): If not determined to be a sole source, an RFP should be prepared based on the required (and desired) capabilities identified in the needs analysis. 11

Items to be included are: w life cycle w costing, w maintenance, w service

Items to be included are: w life cycle w costing, w maintenance, w service / support, w availability, w implementation schedule, installation/training, w financial viability w experience of company, 12

w price (basis), w the evaluation process and criteria, w documentation to be provided

w price (basis), w the evaluation process and criteria, w documentation to be provided by vendor, source code escrow(third party), w example contract, w options such as lease/purchase. w Evaluation criteria, points and process should be identified. 13

Software and Hardware Acquisition cont… w Evaluate Bids or Proposals: Evaluation methods should be

Software and Hardware Acquisition cont… w Evaluate Bids or Proposals: Evaluation methods should be summarized in the specifications, and evaluations should be conducted by a designated evaluation committee. For major acquisitions, a Procurement representative should observe and advise the evaluation committee regarding the evaluation process. 14

Software and Hardware Acquisition cont… w In addition to reviewing technical and financial responses

Software and Hardware Acquisition cont… w In addition to reviewing technical and financial responses in the written proposals, activities that may occur as part of the evaluation process include: product demonstrations, site visits, contacting references, determining responsiveness (e. g. all questions answered, required submittals provided, e. t. c. ). The evaluation process must be well documented. 15

Software and Hardware Acquisition cont… w Negotiate Contract Language: Typically the hardware/software vendor will

Software and Hardware Acquisition cont… w Negotiate Contract Language: Typically the hardware/software vendor will provide a contract to be used. A Procurement representative, and if appropriate, a committee designee will work with the Legal Office to remove or modify language which is unacceptable to the institution, and to add provisions to safeguard the institution’s interests. 16

Software and Hardware Acquisition cont… w Obtain Final Approvals: Appropriate approvals should be sought

Software and Hardware Acquisition cont… w Obtain Final Approvals: Appropriate approvals should be sought and availability of funds verified. w Execute the Contract: With the proper approvals, the contract should be executed. 17

Software Acquisition Dynamics Commercial-Off-The-Shelf (COTS) software is commercial available software. w The supplier might

Software Acquisition Dynamics Commercial-Off-The-Shelf (COTS) software is commercial available software. w The supplier might not be willing to modify and the customer has no control of the quality of the software. w The vender controls the maintenance of the software w Delivery time is immediate w Cost is less 18

Software Acquisition Dynamics… Modified-Off-The –Shelf (MOTS) w The supplier is willing to modify the

Software Acquisition Dynamics… Modified-Off-The –Shelf (MOTS) w The supplier is willing to modify the software according to customer requirements w Customer is in control of maintaining the customized part w Delivery time depends on the modification requirements w Cost depends on the modification requirement 19

Software Acquisition Dynamics… Full developed software w Customer has full control of maintenance and

Software Acquisition Dynamics… Full developed software w Customer has full control of maintenance and quality of the software w The cost could be high w Delivery time long w Could follow water fall method of analysis, design, code and test. Or extreme programming of developing by iterations (incremental) whereby a subset of the requirements is developed in each iteration. 20 w Method of development depends on project

Outsourcing Software Development Can outsource software development w when the services are not available

Outsourcing Software Development Can outsource software development w when the services are not available in-house. w If it is cheaper w If high quality software is required w Lack of resources 21

Challenges of Outsourcing w Could lose control over the software, risk is high due

Challenges of Outsourcing w Could lose control over the software, risk is high due to competition w Do not build internal competence w Development costs could exceed the budget w Time schedule could be overrun w The outcome might not meet expectations w Some projects could be canceled before end of development period w Customer might not take active part in development 22

Challenges of Outsourcing cont… w Focus of client could be more on administrative activities

Challenges of Outsourcing cont… w Focus of client could be more on administrative activities rather than technical issues w Creeping scope - customer keeps adding and changing scope and functionality w Team working on many projects at a time w Introducing new and sophisticated technical solutions rather than simple and proven technology w Performance levels poorly set, qualitative rather than quantitative w No user involvement –important for usability and functionality of the product 23

Challenges of Outsourcing cont… w Lack of discipline of the development team – reverting

Challenges of Outsourcing cont… w Lack of discipline of the development team – reverting to ad hoc development w Unrealistic expectation form the client – having an impossible schedule and/or being unaware of the limitations of the technology being used w Lack of effective communication channels – unable to reach the right people in a timely manner w Conflicts in the team The above problems can be avoided by proper 24 software acquisition management

Implementation Phase Conduct System Test Ø Testing of software packages, custom built programs, and

Implementation Phase Conduct System Test Ø Testing of software packages, custom built programs, and any existing programs that comprise the new system to ensure they work together Ø Task involves Analysts, owners, users and builders 25

Implementation Phase…. § System Analysts- communicates test problems and issues with project team members

Implementation Phase…. § System Analysts- communicates test problems and issues with project team members § System owners and Users – determine if project is operating correctly § System builders – involved in system testing § System tests may result in program modification 26

Implementation Phase…. w Prepare conversion plan Ø Using design Specification for new system, system

Implementation Phase…. w Prepare conversion plan Ø Using design Specification for new system, system analyst prepares a detailed conversion plan Ø Plan identifies, databases to install, end-user training and documentation to develop and conversion strategy from old system to new system. • Tasks facilitated by project manager 27

Implementation Phase…. Installation strategies for conversion plan w Abrupt cut-over / Direct: On a

Implementation Phase…. Installation strategies for conversion plan w Abrupt cut-over / Direct: On a specific date old system is converted and new system starts to operate; Ø High risk approach as system may encounter major problems not yet known, Ø No transition costs Ø Is necessary when policy changes or if system can only be implemented at a given 28 date

Implementation Phase…. w Parallel Conversion: Both Old and New system are operated at the

Implementation Phase…. w Parallel Conversion: Both Old and New system are operated at the same time period Ø Allows detection and solving of problems in new system. Final cut-over may be abrupt or gradual. Ø Strategy minimizes risk of major flaws in new system Ø Costs incurred in running two systems over the period. Ø Increased demand on computing resources 29

Implementation Phase…. w Location Conversion: If the system is to be used in several

Implementation Phase…. w Location Conversion: If the system is to be used in several geographical locations, it is converted at one location first. Once approved in one site, it’s then rolled to the rest. (done either thro’ abrupt or parallel conversion) Others can be cutover. First site usually called beta test site w Staged Conversion: It’s a variation on the abrupt and parallel conversions. § Each successive version of the new system is converted as it is developed. Can be done either thro’ abrupt, parallel, or location strategy. 30

Implementation Phase…. w. Abrupt cutover w. Parallel conversion w. Location conversion w. Staged conversion

Implementation Phase…. w. Abrupt cutover w. Parallel conversion w. Location conversion w. Staged conversion 31

Implementation Phase…. w The Conversion plan typically includes a systems acceptance test plan; w

Implementation Phase…. w The Conversion plan typically includes a systems acceptance test plan; w Systems Acceptance test is the final system test performed by end users using real data over extended period. It’s extensive test and covers 3 levels; – Verification testing (Alpha testing) : - running system in simulated environment using simulated data. The simulation looks for errors and omissions regarding end-user and design specifications as earlier specified but may have 32 not been fulfilled during construction.

Implementation Phase…. – Validation testing (beta testing): - runs system in live environment using

Implementation Phase…. – Validation testing (beta testing): - runs system in live environment using real data. Several things are tested here as follows: ØSystems performance - is throughput and response time for processing adequate to meet normal processing workload? ; If not programs can be written to improve efficiency or hardware may be replaced or upgraded 33

Implementation Phase…. Ø Peak workload processing performance- can the system handle workload during peak

Implementation Phase…. Ø Peak workload processing performance- can the system handle workload during peak processing periods? If not, improved hardware and / or software may be needed to increase efficiency or processing; consider doing some of less critical processing during nonpeak periods. Ø Human engineering test : - is the system as easy to learn and use as anticipated? If not, is it adequate? Can enhancements to human engineering be deferred until after the system has been placed into operation. 34

Implementation Phase…. Ø Methods and procedure test : - during conversion, the methods and

Implementation Phase…. Ø Methods and procedure test : - during conversion, the methods and procedures for new system will be put to their first real test. Methods and procedures may have to be modified if they prove to be awkward and inefficient from users opinion. Ø Backup and recovery testing: - all backup and recovery procedures should be tested. This includes simulating data loss disaster to find and error in recovery procedures. 35

Implementation Phase…. Ø Audit testing – certifies that the system is free of errors

Implementation Phase…. Ø Audit testing – certifies that the system is free of errors and is ready to be placed into operation. Audit not required by all organization, but many firms use independent audit or quality assurance staff that certify systems acceptability and documentation before the system is placed into final operation. 36

Implementation Phase…. w Install Databases Ø To place system into operation you need fully

Implementation Phase…. w Install Databases Ø To place system into operation you need fully loaded databases. Hence installation of databases Ø Purpose of the task is to populate the new system’s databases with existing data from old system. Ø System builders are required in this activity i. e. programmers write special programs to extract data from existing databases and populate new databases 37

Implementation Phase…. w System analysts and designers only perform role of calculating database sizes

Implementation Phase…. w System analysts and designers only perform role of calculating database sizes and time required to perform installation. Main output restructured existing data populated in new system. 38

Implementation Phase…. Train Users w Change to new system requires system users to be

Implementation Phase…. Train Users w Change to new system requires system users to be trained and documentation provided to guide through the new system. w One on One or Group training may be conducted. Group training encouraged w System analysts provide end-user documentation and training for system users but must be supported by system owners 39

Implementation Phase…. w Conversion to New System Ø After conversion, the ownership of the

Implementation Phase…. w Conversion to New System Ø After conversion, the ownership of the system is transferred from analysts and programmers to the end users. § Analysts completes task by carefully carrying out the conversion plan. § This involves completing a systems audit § Task involves System owners, users, analysts, designers and builders. Project 40

Implementation Phase…. – manager oversees the conversion plan – System owners provide feedback regarding

Implementation Phase…. – manager oversees the conversion plan – System owners provide feedback regarding their experiences with the overall project. – System users provide feedback on actual use of the new system. – The feedback may be used by system analysts, designers and builders to correct shortcomings. Thus an operational system is placed into production process of business. 41

Post Implementation Review w A Post-Implementation Review should be scheduled some time after the

Post Implementation Review w A Post-Implementation Review should be scheduled some time after the solution has been deployed. Typical periods range from 6 weeks to 6 months, depending on the type of solution and its environment. The PIR is intended to be an assessment and review of the final working solution. 42

w There should have been at least one full processing and reporting cycle completed.

w There should have been at least one full processing and reporting cycle completed. w It should not be performed while the initial snags are still being dealt with or while users are still being trained, coached and generally getting used to its operation. 43

Post Implementation Review… w There is often a difference of opinion as to who

Post Implementation Review… w There is often a difference of opinion as to who should perform the Post. Implementation Review. Usually, members of the project team will want to complete the review as a natural extension of their responsibility to deliver optimum benefit from the solution. They understand what was required, what was changed, how it was achieved, how things are supposed to 44 work, how to fix problems, etc.

w There is a converse argument that the review should be performed by an

w There is a converse argument that the review should be performed by an independent team. This reduces the risk that any errors or omissions of the project team might equally be overlooked in their review. 45

Post Implementation Review… w A solution is to do both. An independent audit team,

Post Implementation Review… w A solution is to do both. An independent audit team, working in consultation with the business users and project team, could examine whether the results are satisfactory. The project team might then reconvene to consider that input and also to examine how to generate further value from the solution. w A cost/benefit analysis of the system should be done. 46

Post Implementation Review… Post Implementation should include such questions as: w Is the required

Post Implementation Review… Post Implementation should include such questions as: w Is the required functionality available? w Have users received adequate training and coaching to take advantage of the new facilities? w Are staffing levels and skill sets appropriate for the actual workloads? w Are staff displaying appropriate attitudes to get the best out of the system (confidence in its capabilities, belief in its purpose, willingness to make it work, etc)? w Are third parties such as customers and suppliers 47 satisfied with the service?

Post Implementation Review… w Is data integrity being maintained within the system and in

Post Implementation Review… w Is data integrity being maintained within the system and in relation to other integrated or interfaced systems? w Are systems controls being applied correctly? w Is the system able to process transactions at an adequate speed? w Does the system have the capacity to deal with the actual peak loadings as encountered and foreseen? w Are staff following operational procedures including backup, recovery, security and disaster 48 recovery?

Post Implementation Review… w These questions will be investigated through a combination of investigative

Post Implementation Review… w These questions will be investigated through a combination of investigative techniques including interviews, examination of documentation, performance statistics, hands-on tests and checks, etc. Implications and potential remedial options would then be assessed and evaluated. The findings and recommended actions would be prepared, normally in the form of a report or presentation. 49

SYSTEMS SUPPORT 50

SYSTEMS SUPPORT 50

System support w This is the ongoing technical support for users, as well as

System support w This is the ongoing technical support for users, as well as the maintenance required to fix any errors, omissions, or new requirements that may arise. w Before an information system can be supported it must be in operation. 51

System support…. w System operation is the day-to-day, week-toweek, month to month, and year

System support…. w System operation is the day-to-day, week-toweek, month to month, and year to year execution of an information system’s business processes and application programs w Unlike system analysis and design and implementation systems support cannot be sensibly decomposed into actual phases that a support project must perform. 52

System support Each activity is a type of a support project that is triggered

System support Each activity is a type of a support project that is triggered by a particular problem, event, or opportunity encountered with the implemented system. w Program maintenance – Unfortunately, most systems suffer from software defects or bugs, errors that slipped through the testing of software 53

System support w System recovery – from time to time, a system failure may

System support w System recovery – from time to time, a system failure may result in a program “crash” and/or loss of data. Human error or a hardware or software failure may have caused this. The systems analyst or technical support specialist may then be called on to recover the system – that is to restore a system’s files and databases and to restart the system. 54

System support w Technical support - Regardless of how well the users have been

System support w Technical support - Regardless of how well the users have been trained and how good the end-user documentation is, users will eventually require additional assistance – unanticipated situations arise and even new users are added. w System enhancement – New requirements may include new business problems, new business requirements, new technical problems, or new technology requirements. 55

System Maintenance Regardless of how well designed, constructed, and tested a system or application

System Maintenance Regardless of how well designed, constructed, and tested a system or application be, errors or bugs will inevitable occur. Bugs can be caused by any of the following. w w w Poorly communicated requirements Misinterpreted requirements Poorly validated requirements Incorrectly implemented requirements or designs Simple misuse of the programs 56

System Maintenance - Objectives w To make predictable changes to existing programs w to

System Maintenance - Objectives w To make predictable changes to existing programs w to correct errors that are made during systems design or implementation. w To preserve those aspects of the programs that were correct and to avoid the possibility that “fixes” to programs cause other aspects of those programs to behave differently. 57

System Maintenance - Objectives To avoid as much as possible, degradation of system performance,

System Maintenance - Objectives To avoid as much as possible, degradation of system performance, poor system maintenance can gradually erode system throughput and response time. To complete the task as quickly as possible without sacrificing quality and reliability. Few operational information systems can afford to be down for any extended period. 58

System Maintenance w Tasks involved are – Validate the problem – Benchmark the problem

System Maintenance w Tasks involved are – Validate the problem – Benchmark the problem – Study and debug the program – Test the program 59

Validate the problem System maintenance (miniprojects) are triggered by the identification of the problem,

Validate the problem System maintenance (miniprojects) are triggered by the identification of the problem, usually called a bug. Most such bugs are identified by users when they discover some aspect of the system that does not appear to be working as it should. The first task of the systems analyst or programmer is to validate the problem. 60

Validate the problem… Working with the users, the team should attempt to validate the

Validate the problem… Working with the users, the team should attempt to validate the problem by reproducing it. If the problem cannot be reproduced, the project should be suspended until the problem recurs and the user can explain the circumstance under which it occurred. 61

Validate the problem The “as-is” program is executed, as closely as possible approximating the

Validate the problem The “as-is” program is executed, as closely as possible approximating the circumstances and the data that were present when the problem was first encountered. In most cases, the user who encountered the problem should be the one who re-creates it. Do not blame the user. 62

Benchmark program Given a copy of the program with a substantiated bug, the analyst

Benchmark program Given a copy of the program with a substantiated bug, the analyst should benchmark the program. A program is not all bad, or it would have never been placed into operation. System maintenance can result in unpredictable and undesirable side effects that impact the program’s or application’s overall functionality and performance. 63

Validate the problem…. w For this reason, before making any changes to programs, the

Validate the problem…. w For this reason, before making any changes to programs, the programs should be executed and tested to establish a baseline against which the modified programs and applications can later be measured. w This task can be performed by the systems analyst and/or programmer. Users should also participate to ensure the test is conducted under circumstances that simulate as closely as possible a normal working environment. 64

Study and Debug the Program The primary task in system maintenance is to make

Study and Debug the Program The primary task in system maintenance is to make the required changes to the programs. This task is performed by the application programmer. Essentially, the programmer responds to “bug-fix” requirements that establish the expectation for fixing the problem. 65

Study and Debug the Program… The programmer “debugs” (edits) a copy of the problem

Study and Debug the Program… The programmer “debugs” (edits) a copy of the problem program. Changes are not made to the production program. The result is a corrected version of the program. This is a candidate release, meaning a candidate to become the next production version of the program. 66

Study and Debug the Program… Application and program knowledge usually comes from studying the

Study and Debug the Program… Application and program knowledge usually comes from studying the source code. Program understanding can take considerable time. This activity is slowed by some combination of the following limitations: Poor program structure – examples include structural programs written with non-structured techniques and Visual Basic or Java programs written with non-object-oriented techniques. 67

Study and Debug the Program… – Prior maintenance (quick fixes and poorly designed extensions).

Study and Debug the Program… – Prior maintenance (quick fixes and poorly designed extensions). – Dead code (instructions that cannot be reached or executed – often leftovers from prior testing and debugging). – Poor or inadequate documentation 68

Study and Debug the Program… w Changes that you make may have an undesirable

Study and Debug the Program… w Changes that you make may have an undesirable ripple through other parts of the program or, worse still, other programs in the application and information system. w A candidate release of the program must be tested before it can be placed into operation as the next new version of the production program. The following tests are essential or recommended: 69

Study and Debug the Program. . . Unit testing (essential) ensure that the stand-alone

Study and Debug the Program. . . Unit testing (essential) ensure that the stand-alone program fixes the bug without undesirable side effects to the program. The test data and current performance that you recovered, created, or generated when the programs were benchmarked are used here. System testing (essential) ensures that the entire application, of which the modified program was a part, still works. Again, the test data and current performance are used here. 70

Study and Debug the Program… – Regression testing (recommended) extrapolates (predict) the impact of

Study and Debug the Program… – Regression testing (recommended) extrapolates (predict) the impact of the changes on program and application throughput and response time from the beforeand-after results using the test data and current performance. 71

System Recovery From time to time a system failure is inevitable. It generally results

System Recovery From time to time a system failure is inevitable. It generally results in an aborted or “hung” program (also called a “crash”) and may be accompanied by loss of transactions or stored business data. The systems analyst often fixes the system or acts as intermediary between the users and those who can fix the system. 72

Technical Support w Another relatively routine ongoing activity of systems support is technical support.

Technical Support w Another relatively routine ongoing activity of systems support is technical support. w No matter how well users have been trained or how well documentation has been written, users will require additional assistance. The systems analyst is generally on call to assist users with the day-to-day use of specific applications. 73

Technical Support… The most typical tasks include: Routinely observing the use of the system.

Technical Support… The most typical tasks include: Routinely observing the use of the system. Conducting meetings. user-satisfaction surveys and Changing business procedures for clarification (written and in the repository). Providing additional training as necessary. Logging enhancement ideas and requests in the repository. 74

System Enhancement Adapting an existing system to new requirements is the norm for all

System Enhancement Adapting an existing system to new requirements is the norm for all information systems. Business is change! The pace of change in today’s economy is accelerated, and rapid response is the expectation. System enhancement requires that the systems analyst evaluate a new requirement to either effect change or direct the change request through an appropriate subset of the original systems development process. 75

System Enhancement… System enhancement is an adaptive process. Most such enhancement is in response

System Enhancement… System enhancement is an adaptive process. Most such enhancement is in response to one of the following events: New business problems – A new or anticipated business problem will make a portion of the current system unusable or ineffective. New business requirements – A new business requirement (e. g. New report, transaction, policy or event) is needed to sustain the value of the current system. 76

System Enhancement… New technology requirements – A decision to consider or use a new

System Enhancement… New technology requirements – A decision to consider or use a new technology (eg. New software or version, or different type of hardware) in an existing system needs to be made. New design requirements – An element of the existing system needs to be redesigned against the same business requirements (e. g. Add new database tables or fields, add or change to a new interface, etc). 77

System Enhancement… Systems enhancement is reactionary in nature – fix it when it breaks

System Enhancement… Systems enhancement is reactionary in nature – fix it when it breaks or when users or managers request change. System enhancement extends the useful life of an existing system by adapting it to inevitable change. 78

System Enhancement… This objective can be linked to your information system building blocks as

System Enhancement… This objective can be linked to your information system building blocks as follows: KNOWLEDGE/DATA – Many system enhancements are requests for new information (reports or screens) that can be derived from existing stored data. But some data enhancements call for the restructuring or stored data. 79

System Enhancement… PROCESSES – Most system enhancements require the modification of existing programs or

System Enhancement… PROCESSES – Most system enhancements require the modification of existing programs or the creation of new programs to extend the overall application system. But some enhancement requests can be accomplished through careful redesign of existing business processes. COMMUNICATION – Many enhancements require modifications to how the users interface with the system and how the system interfaces with other systems. 80

System Obsolescence At some point, it will not be cost-effective to support and maintain

System Obsolescence At some point, it will not be cost-effective to support and maintain an information system. All systems degrade over time. And when support and maintenance become cost-ineffective, a new systems development project must be started to replace the system. 81

THE END THANK YOU 82

THE END THANK YOU 82