Chapter 7 System Design and Implementation Power Point

Chapter 7 System Design and Implementation Power. Point Presentation by Charlie Cook Copyright © 2004 South-Western. All rights reserved.

Learning Objectives • To name the goals, plans, tasks, and results of systems design, implementation, and operation • To be able to evaluate the advantages and disadvantages of alternative sources for computer software and computer hardware • To describe the process of choosing computer software and hardware • To explain the importance of implementation planning Copyright © 2004 South-Western. All rights reserved. 2

Learning Objectives (cont’d) • To name the interdependent tasks that must be accomplished during systems implementation • To explain the importance of thoroughly testing the new or revised system prior to putting the system into operation • To describe the dual functions of postimplementation review • To explain the difficulties associated with systems maintenance Copyright © 2004 South-Western. All rights reserved. 3

System Selection Goals • Determine what computer software will implement logical specifications. • Determine what computer hardware will implement physical requirements. • Choose acquisition financing methods. • Determine appropriate acquisition ancillaries. Copyright © 2004 South-Western. All rights reserved. 4

Systems Development Life Cycle: Design and Implementation FIGURE 7. 1 Copyright © 2004 South-Western. All rights reserved. 5

Approved Configuration Plan • Choose software package and expected performance specifications. • Chosen hardware type, manufacturer, model, and expected performance specifications. • Items for software and hardware contracts. • Results of testing alternative software and hardware. • Assessment of financing and outsourcing alternatives. Copyright © 2004 South-Western. All rights reserved. 6

Acquisition Alternatives Software • Internal development • External acquisition Hardware • Internal acquisition • Purchase Ø Outsourcing to an application service provider (ASP) Ø Service bureaus Ø System integrators Ø Rental (operating lease) Ø Capital lease Copyright © 2004 South-Western. All rights reserved. • External acquisition Ø Outsourcing Ø Facilities management 7

Request for Proposal • Descriptions of scope of request Ø Hardware Ø Software Ø Services • System description that includes logical and physical specifications Ø Inputs and outputs Ø Data storage processes Ø Controls Copyright © 2004 South-Western. All rights reserved. 8

Request for Proposal (cont’d) • Procedures for submitting proposals Ø Timetable Ø Evaluation methods Ø Final decision date • Price/budget constraints • Vendor information required Ø Contract terms Ø Warranty Ø General company information Copyright © 2004 South-Western. All rights reserved. 9

Request for Proposal (cont’d) • Hardware performance objectives Ø Storage capacity and access Ø Input/output speed and volumes Ø Data communications requirements Ø Computational demands • Software performance objectives Ø Inputs and outputs Ø File sizes and access requirements Ø Utilities and language compilers Copyright © 2004 South-Western. All rights reserved. 10

Request for Proposal (cont’d) • Projected growth requirements Ø Expected changes in volumes Ø Modularity/expandabilit y requirements Copyright © 2004 South-Western. All rights reserved. • Evaluation criteria Ø Ability to meet performance criteria Reliability v Documentation v Training v Backup v Cost v Ease of use v Expandability v 11

Evaluate Vendor Proposals • Validate vendor proposals. • Consider other data and criteria. • Suggest resources. Copyright © 2004 South-Western. All rights reserved. 12

Evaluating Vendors’ Systems • An evaluation team can test a system by: Ø Varying input (workload) parameters, such as quantity, timing, and type of input. Ø Varying system characteristics (parameters), such as quantity and size of data storage devices. Ø Varying the factors being measured, such as CPU cycle time (a system parameter) or execution time (a performance measure). Ø Testing an actual workload, such as a weekly payroll, or testing a workload model that is representative of the workload. Ø Testing the actual system or a model of the system. Copyright © 2004 South-Western. All rights reserved. 13

External interviews • Interviews with personnel outside the organization can provide valuable insights into performance. Ø Were there delays in obtaining the software or hardware? Ø Did the system have bugs? Ø How responsive is the vendor to requests for service? Ø Was the training the vendor provided adequate? Copyright © 2004 South-Western. All rights reserved. 14

Completing the Configuration Plan • Software plan Ø Documents how the logical specification will be implemented, using in-house development, vendor purchase or lease, ASP, or a combination of these. • Hardware plan Ø Summarizes how the recommended vendor proposal will fulfill the physical requirements specified in structured systems analysis. • Prepare configuration plan (combine plans) • Obtain approvals Copyright © 2004 South-Western. All rights reserved. 15

Structured System Design Goals • Convert structured specification into reliable, maintainable design. • Develop plan and budget for orderly and controlled implementation. • Develop implementation test plan. • Develop user manuals. • Develop training program. Copyright © 2004 South-Western. All rights reserved. 16

Approved Systems Design Document • The system design Ø Structure charts and descriptions of logical processes • The implementation, testing, and training plans • The user manual Copyright © 2004 South-Western. All rights reserved. 17

Systems Implementation Goals • Complete design from design document • Acquire hardware and software • Write, configure, test, design, and document computer software • Select, train and educate personnel • Complete user manual • Test system • Obtain approvals • Conduct conversion Copyright © 2004 South-Western. All rights reserved. 18

Implementation Approaches FIGURE 7. 2 Copyright © 2004 South-Western. All rights reserved. 19

Boston Scientific Global Roll-Out Schedule Source: Reprinted with permission from Dave Ellard, Vice President, Global Systems, Boston Scientific Corporation. Copyright © 2004 South-Western. All rights reserved. FIGURE 7. 3 20

System Testing • The system test Ø Verifies the new system against the original specifications by the development team and then by the users with the assistance of the team. • The acceptance test Ø A user-directed test of the complete system in a test environment to determine whether all components of the new system are satisfactory. • The operations test or environmental test Ø Testing in a production environment to determine if equipment and other factors are satisfactory. Copyright © 2004 South-Western. All rights reserved. 21

Periodic Examination of Systems • The post-implementation review Ø Conducted to follow up a system’s recent implementation. • Systems maintenance Ø In response to a specific request, testing is conducted if the system has a relatively minor deficiency. • The periodic systems survey Ø Undertaken whenever it is likely that the costs of the review will be less than the value of the improvements that the review will suggest. This reevaluation is like a periodic physical examination. Copyright © 2004 South-Western. All rights reserved. 22

Boston Edison Bill to Accompany Problem 7 -4 FIGURE 7. 4 a Copyright © 2004 South-Western. All rights reserved. 23

Boston Edison Bill to Accompany Problem 7 -4 (cont’d) FIGURE 7. 4 b Copyright © 2004 South-Western. All rights reserved. 24

Boston Edison Bill to Accompany Problem 7 -4 (cont’d) FIGURE 7. 4 c Copyright © 2004 South-Western. All rights reserved. 25

Program Flowchart to Accompany Problem 7 -6 FIGURE 7. 5 Copyright © 2004 South-Western. All rights reserved. 26