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

2. Copyright © 2004 South-Western. All rights reserved.7–2 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

3. Copyright © 2004 South-Western. All rights reserved.7–3 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 post- implementation review To explain the difficulties associated with systems maintenance

4. Copyright © 2004 South-Western. All rights reserved.7–4 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.

5. Copyright © 2004 South-Western. All rights reserved.7–5 Systems Development Life Cycle FIGURE 6.1

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

7. Copyright © 2004 South-Western. All rights reserved.7–7 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.

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

9. Copyright © 2004 South-Western. All rights reserved.7–9 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

10. Copyright © 2004 South-Western. All rights reserved.7–10 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

11. Copyright © 2004 South-Western. All rights reserved.7–11 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

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

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

14. Copyright © 2004 South-Western. All rights reserved.7–14 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.

15. Copyright © 2004 South-Western. All rights reserved.7–15 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?

16. Copyright © 2004 South-Western. All rights reserved.7–16 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

17. Copyright © 2004 South-Western. All rights reserved.7–17 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.

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

19. Copyright © 2004 South-Western. All rights reserved.7–19 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

20. Copyright © 2004 South-Western. All rights reserved.7–20 Implementation Approaches FIGURE 7.2

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

22. Copyright © 2004 South-Western. All rights reserved.7–22 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.

23. Copyright © 2004 South-Western. All rights reserved.7–23 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.

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

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

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

27. Copyright © 2004 South-Western. All rights reserved.7–27 Program Flowchart to Accompany Problem 7-6 FIGURE 7.5