1 / 52

Evaluating Software Alternatives: In-House Development vs. Software Packages

Learn about the pros and cons of in-house development versus purchasing software packages, including steps in purchasing and evaluating, RFP vs. RFQ, system requirements document, prototyping, CASE tools, and flowcharts. Explore outsourcing, end-user systems, and enterprise computing options.

rcooper
Download Presentation

Evaluating Software Alternatives: In-House Development vs. Software Packages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SYSTEMS ANALYSIS & DESIGN PHASE 2 SYSTEMS ANALYSIS Evaluating Alternatives and Strategies

  2. Chapter 5 Evaluating Alternatives and Strategies

  3. Objectives • Evaluate various alternatives when planning systems development and acquisition • Explain the advantages and disadvantages of in-house development versus purchasing a software package • List the steps in purchasing and evaluating a software package

  4. Objectives • Explain the differences between a request for proposal (RFP) and a request for quotation (RFQ) • Describe the contents of the system requirements document and explain its purpose • Explain the prototyping process and describe a typical situation where prototyping is used

  5. Objectives • Describe computer-aided software engineering (CASE) tools and explain how they are used during the systems development life cycle • Explain how systems flowcharts and state-transition diagrams are used

  6. Chapter 5 covers the remaining tasks in the systems analysis phase Evaluation of alternative solutions Preparation of the system requirements document Presentation to management Introduction

  7. Click to see Figure 5-1 Evaluating Software Alternatives • Make or buy decision • In-house software • Developed by the company’s IS department • Software package • Purchased or leased from software publishers or vendors • Horizontal application • Vertical application

  8. Click to see Figure 5-2 Evaluating Software Alternatives • Developing software in-house • Reasons for in-house development • Satisfy unique requirements • Minimize changes in business procedures and policies • Meet constraints of existing systems • Meet constraints of existing technology • Develop internal resources and capabilities

  9. Click to see Figure 5-2 Evaluating Software Alternatives • Buying a software package • Reasons for buying a software package • Lower costs • Requires less time to implement • Proven reliability and performance benchmarks • Implemented by other companies • Requires less technical development staff • Future upgrades provided by the vendor

  10. Evaluating Software Alternatives • Customizing software packages • Purchase a basic package that can be customized to suit your needs • Negotiate with software vendor to make enhancements to suit your needs • Purchase the package and make your own modifications

  11. Evaluating Software Alternatives • Other software alternatives • Outsourcing • End-user systems • Enterprise computing

  12. Evaluating Software Alternatives • Outsourcing • Using outside companies to handle part of the workload, on short-term or long-term basis • Contract personnel firms • Systems management or facilities management firms

  13. Click to see Figure 5-3 Evaluating Software Alternatives • End-user systems • Major factor in systems planning and development • Applications can be managed by end-users

  14. Click to see Figure 5-4 Evaluating Software Alternatives • End-user systems • Major factor in systems planning and development • Applications can be managed by end-users • Software suites offer integrated applications • Interactive Help features include wizards • Security concerns might require read-only files • Information centers (IC) can support end-user systems

  15. Evaluating Software Alternatives • Enterprise computing • Overall information management strategy • Key is effective integration of information resources • Many systems involve client/server architecture

  16. Click to see Figure 5-5 Evaluating Software Alternatives • Selecting a software alternative • Decision will affect remaining SDLC phases • Systems analyst’s involvement depends on which alternative is selected

  17. Steps in Evaluating and Purchasing Software Packages • Five step process 1. Evaluate the information system requirements 2. Identify potential software vendors 3. Evaluate software package alternatives 4. Make the purchase 5. Install the software package

  18. Click to see Figure 5-6 Steps in Evaluating and Purchasing Software Packages Step 1: evaluate the information system requirements • Identify the key features of the system • Estimate volume and future growth • Specify any hardware constraints • Prepare a request for proposal or quotation

  19. Click to see Figure 5-7 Steps in Evaluating and Purchasing Software Packages Step 2: identify potential software vendors • Next step is to contact potential vendors • An RFP will help vendors to identify solutions • Various sources of information on suppliers • Retailers • Computer manufacturers • Industry trade journals • Systems consultants

  20. Click to see Figure 5-8 Steps in Evaluating and Purchasing Software Packages Step 3: evaluate software package alternatives • Object is to compare software packages and select the best alternative • Obtain information from many sources • Vendor presentations and literature

  21. Click to see Figure 5-9 Steps in Evaluating and Purchasing Software Packages Step 3: evaluate software package alternatives • Object is to compare software packages and select the best alternative • Obtain information from many sources • Vendor presentations and literature • Product documentation • Trade publications • Companies that perform software testing/evaluation

  22. Click to see Figure 5-10a Click to see Figure 5-10b Steps in Evaluating and Purchasing Software Packages Step 3: evaluate software package alternatives • Object is to compare software packages and select the best alternative • Obtain information from many sources • Vendor presentations and literature • Product documentation • Trade publications • Companies that perform software testing/evaluation • Contact users of the package • Benchmark test

  23. Steps in Evaluating and Purchasing Software Packages Step 4: make the purchase • Software licenses • Lease agreements • Maintenance agreements

  24. Steps in Evaluating and Purchasing Software Packages Step 5: install the software package • Installation time depends on size and complexity • Before using the package, complete all implementation steps • Loading, configuring, and testing the software • Training users • Converting data files to new format

  25. Click to see Figure 5-11 Hardware Alternatives • Hardware decisions use the same five-step approach as software decisions • Evaluate system requirements • Identify potential hardware vendors • Evaluate hardware alternatives • Make the purchase • Install the hardware

  26. Hardware Alternatives • Other issues to consider • Turnkey systems • Site preparation • New workstations • Network cabling • Raised floors • Conditioned electrical lines • Fire extinguishing equipment • Uninterruptible power supplies (UPSs)

  27. TRADEOFF • How do you select the best alternative? • Most companies combine • In-house developed software • Software packages • Outsourcing • End-user systems • Object is to develop a list of viable alternatives • All viable alternatives must be evaluated • Feedback from users is essential

  28. A KEY QUESTION • How will you prepare for the meeting with Doug Sawyer? • What is your strategy and how will you present your alternatives? • Consider the pros and cons of in-house development vs. purchase of a package

  29. Completion of Systems Analysis • System requirements document • Also called software requirements specification • Describes alternatives and makes recommendation to management • Similar to a contract for what will be delivered • Must be clear and understandable to users

  30. Completion of Systems Analysis • Presentation to management • Five probable management decisions 1. Develop an in-house system 2. Modify the current system 3. Purchase or customize a software package 4. Perform additional systems analysis work 5. Stop all further work

  31. Completion of Systems Analysis • Presentation guidelines and suggestions • Give overview of the project’s purpose and objectives • Summarize alternatives, with costs, pros, and cons • Explain why the recommended alternative was chosen • Allow time for discussion, questions, and answers • Obtain final decision from management or timetable for next step

  32. Prototyping • A prototype is an early, rapidly constructed working version of the system • A working model helps users understand the system • Prototyping produces a less-expensive model • Can eliminate problems before the final version

  33. Click to see Figure 5-12 Prototyping • Prototyping software tools • Nonprocedural tools specify the problem to be solved, rather than how to solve it • Fourth-generation environment prototyping tools • CASE toolkit

  34. Click to see Figure 5-13 Prototyping • Prototyping software tools • Nonprocedural tools specify the problem to be solved, rather than how to solve it • Fourth-generation environment prototyping tools • CASE toolkit • Report writer or report generator

  35. Click to see Figure 5-14a Click to see Figure 5-14b Prototyping • Fourth-generation environment prototyping tools • CASE toolkit • Report writer or report generator • Query language • Screen generator, screen painter, screen mapper, or form generator • Program generator or code generator • Fourth-generation language (4GL)

  36. Click to see Figure 5-15 Prototyping • Prototyping during systems analysis • Goal is to develop a working model quickly • Early way to test essential system features • Prototype can be upgraded or replaced during later SDLC phases

  37. Click to see Figure 5-16 Click to see Figure 5-17 Computer-Aided SoftwareEngineering (CASE) • CASE tools increase productivity • Full set of CASE tools is called a toolkit • CASE tools can handle variety of tasks • Create and integrate data flow diagrams • Logical and physical design • Generation of program code • CASE tool example is Visible Analyst

  38. Click to see Figure 5-18 Computer-Aided SoftwareEngineering (CASE) • Categories of CASE tools • Diagramming tools

  39. Click to see Figure 5-19a Click to see Figure 5-19b Computer-Aided SoftwareEngineering (CASE) • Categories of CASE tools • Diagramming tools • Prototyping tools • Central repository

  40. Click to see Figure 5-20 Computer-Aided SoftwareEngineering (CASE) • Categories of CASE tools • Diagramming tools • Prototyping tools • Central repository • Data design tools • Project management tools • Maintenance tools • Another CASE example: Hyper Analysis Toolkit (HAT)

  41. Click to see Figure 5-21a Click to see Figure 5-21b Computer-Aided SoftwareEngineering (CASE) • Using CASE tools • Data design tool • Programming tool • Program debugger • Code generator • Project management tool • Maintenance tool

  42. Computer-Aided SoftwareEngineering (CASE) • Categories of tools • Forward engineering tools (used during SDLC work) • Reverse engineering tools (convert program code into design specifications) • Reengineering toolkit (uses reverse and forward engineering) • Front-end, or upper-CASE tools (used in first three SDLC phases) • Back-end, or lower-CASE tools (used during systems implementation and operation phases)

  43. TRADEOFF • Pros and cons of CASE tools • Advantages • Automate manual tasks • Encourage standard methods • Improve accuracy and overall quality of end product

  44. TRADEOFF • Disadvantages • Cost of CASE software and hardware needed • Lack of CASE standards • Other issues • CASE does not replace need for analyst’s skills • Initial preparation effort not always worthwhile

  45. A KEY QUESTION • Does the new CASE toolkit at Sunnyside Beverages replace the need to teach new analysts how to create DFDs? • How would you respond?

  46. Alternative Graphical Tools • Other tools can be used in addition to DFDs • Systems flowcharts • State-transition diagrams

  47. Click to see Figure 5-22 Alternative Graphical Tools • Systems flowcharts • Display major process, input, and output operations • Primarily used in physical modeling • Various symbols represent data or files in specific physical media • Shape of symbol indicates the purpose • Lines with arrowheads indicate the flow of data

  48. Click to see Figure 5-23 Click to see Figure 5-24 Alternative Graphical Tools • State-transition diagrams • Show time sequence of real-time systems • A real-time system processes data and feeds it back to the system • Real-time system examples • Automobile cruise control systems • Microprocessor-controlled thermostats • Microwave oven control system

  49. Transition to Systems Design • Next SDLC phase is system design for in-house system development • Size of the development team depends on the company and the nature of the project • System requirements document • An accurate and understandable document is essential • Document contains design for the new system • Must reflect thorough analysis and effective communication

  50. SOFTWEAR, LIMITED • Rick and Carla attend training workshop for SWL’s new CASE toolkit: Visible Analyst • The development team evaluates various alternatives and potential solutions • The IS department recommendations: 1. Purchase a commercial package for payroll functions from Pacific Software Solutions 2. Develop an ESIP system in-house to meet SWL’s unique requirements

More Related