Chapter 5

1. Chapter 5 Data and Process Modeling

2. Chapter Objectives • Describe software trends, including the concept of software as a service • Explain software acquisition alternatives, including traditional versus Web-based software development strategies • Describe software outsourcing options, including the role of service providers • Explain advantages and disadvantages of developing software in-house versus other alternatives

3. Chapter Objectives • Explain cost-benefit analysis and financial analysis tools • Explain the differences between a request for proposal (RFP) and a request for quotation (RFQ) • Describe the contents of the system requirements document

4. Chapter Objectives • Explain the transition from systems analysis to systems design, and the difference between logical and physical design • Explain the transition to systems design and the importance of prototyping • Discuss guidelines for system design, and explain the importance of codes

5. Introduction • Chapter 5 describes the remaining activities in the systems analysis phase • The chapter also describes the transition to systems design, prototyping, design guidelines, and using codes to represent values and simplify data entry

6. Development Strategies Overview • Selecting the best development path is an important decision that requires companies to consider three key issues • Web-based software trends • Software outsourcing options • In-house software development alternatives

7. Systems Development

8. Web-Based Software Trends • The Changing Software Marketplace • In the traditional model, software vendors develop and sell application packages to customers • In addition to traditional vendors, the marketplace now includes many forms of outsourcing, including application service providers (ASP) and firms that offer Internet business services

9. Software Outsourcing Options • Outsourcing is the transfer of information systems development, operation, or maintenance to an outside firm that provides these services, for a fee, on a temporary or long-term basis • Can refer to relatively minor programming tasks or the handling of a company’s entire IT function

10. Software Outsourcing Options • The Growth of Outsourcing • Traditionally, firms outsourced IT tasks as a way of controlling costs and dealing with rapid technological change • Today, outsourcing is a vital business issue that shapes a company’s overall IT strategy • the most important factor is the potential saving in operating costs

11. Software Outsourcing Options • The Growth of Outsourcing • A firm that offers outsourcing solutions is called a service provider • Application service providers (ASP) • Internet business services (IBS) • Also called managed hosting

12. Software Outsourcing Options • Outsourcing Fees • A fixed fee model uses a set fee based on a specified level of service and user support • A subscription model has a variable fee based on the number of users or workstations that have access • A usage model or transaction model charges a variable fee based on the volume of transactions or operations

13. Software Outsourcing Options • Outsourcing Issues and Concerns • Mission-critical IT systems should be out-sourced only if the result is a cost-attractive, reliable, business solution that fits the company’s long-term business strategy • out-sourcing can also affect day-to-day company operations and can raise some concerns

14. Software Outsourcing Options • Outsourcing Issues and Concerns • A company must plan outsourcing carefully to avoid lost revenue, added expenses, and potential litigation • The solution can be only as good as the outsourcing firm that provides the service • Outsourcing can be especially attractive to a company whose volume fluctuates widely • A major disadvantage of outsourcing is that it raises employee concerns about job security

15. In-House Software Development Options • A company can choose to develop its own systems, or purchase, possibly customize, and implement a software package • The most important consideration is total cost of ownership (TCO) • Companies also develop user applications designed around commercial software packages

16. In-House Software Development Options • Make or Buy Decision • The choice between developing versus purchasing software often is called a make or buy, or build or buydecision • The company’s IT department makes, builds, and develops in-house software • A software packageis obtained from a vendor or application service provider.

17. In-House Software Development Options • Make or Buy Decision • Companies that develop software for sale are called software vendors • Value-added reseller (VAR) • Vertical application (PkMS) • Horizontal application (MS Money)

18. In-House Software Development Options • Purchasing a Software Package • Lower costs • Requires less time to implement • Proven reliability and performance benchmarks • Requires less technical development staff • Future upgrades provided by the vendor • Input from other companies

19. In-House Software Development Options • Developing Software In-House • Satisfy unique business requirements • Minimize changes in business procedures and policies • Meet constraints of existing systems • Meet constraints of existing technology • Develop internal resources and capabilities

20. In-House Software Development Options • Customizing a Software Package • You can purchase a basic package that vendors will customize to suit your needs • You can negotiate directly with the software vendor to make enhancements to meet your needs by paying for the changes • You can purchase the package and make your own modifications, if this is permissible under the terms of the software license

21. Considerations in make, buy, customize decision • Cost • Time • Skills available • Technology available • Knowledge Base

22. A Software Acquisition Example • Step 1: Evaluate the Information System Requirements • Identify key features • Consider network and web-related issues • Estimate volume and future growth • Specify hardware, software, or personnel constraints • Prepare a request for proposal or quotation • Request for proposal (RFP) • Evaluation model • Request for quotation (RFQ)

23. A Software Acquisition Example • Step 2: Identify Potential Vendors or Outsourcing Options • The Internet is a primary marketplace • Another approach is to work with a consulting firm • Another resource is the Internet bulletin board systems that contains thousands of forums, called newsgroups

24. A Software Acquisition Example • Step 3: Evaluate the Alternatives • Existing users • Application testing • Benchmarks • Match each package against the RFP features and rank the choices

25. A Software Acquisition Example • Step 4: Perform Cost-Benefit Analysis • Identify and calculate TCO for each option you are considering • When you purchase software, what you are buying is a software license • If you purchase a software package, consider a maintenance agreement

26. A Software Acquisition Example • Step 5: Prepare a Recommendation • You should prepare a recommendation that contains your recommendation and lists the alternatives, together with the costs, benefits, advantages, and disadvantages of each option • At this point, you may be required to submit a formal system requirements document and deliver a presentation

27. A Software Acquisition Example • Step 6: Implement the Solution • Implementation tasks will depend on the solution selected • Before the new software becomes operational, you must complete all implementation steps, including loading, configuring, and testing the software; training users; and converting data files to the new system’s format

28. Completion of Systems Analysis Tasks • System Requirements Document • The system requirements document, or software requirements specification, contains the requirements for the new system, describes the alternatives that were considered, and makes a specific recommendation to management • Like a contract • Format and organize it so it is easy to read and use

29. Completion of Systems Analysis Tasks • Presentation to Management • Begin your presentation with a brief overview of the purpose and primary objectives of the system project • Summarize the primary viable alternatives. For each alternative, describe the costs, advantages, and disadvantages

30. Completion of Systems Analysis Tasks • Presentation to Management • Explain why the evaluation and selection team chose the recommended alternative • Allow time for discussion and for questions and answers • Obtain a final decision from management or agree on a timetable for the next step in the process

31. Completion of Systems Analysis Tasks • Presentation to Management • Based on their decision, your next task will be one of the following • Implement an outsourcing alternative • Develop an in-house system • Purchase or customize a software package • Perform additional systems analysis work • Stop all further work

32. The Transition to System Design • If management decides to develop the system in-house, then the transition to the systems design phase begins • Preparing for Systems Design Tasks • It is essential to have an accurate and understandable system requirements document

33. The Transition to System Design • The Relationship between Logical and Physical Design • The logical design defines the functions and features of the system and the relationships among its components • The physical design of an information system is a plan for the actual implementation of the system

34. Systems Design Guidelines • The systems analyst must understand the logical design of the system before beginning the physical design of any one component • Data design • User interface • System design specification

35. Systems Design Guidelines • System Design Objectives • The goal of systems design is to build a system that is effective, reliable, and maintainable • A system is reliable if it adequately handles errors • A system is maintainable if it is well designed, flexible, and developed with future modifications in mind

36. Systems Design Guidelines • System Design Objectives • User considerations • Carefully consider any point where users receive output from, or provide input to, the system • Anticipate future needs of the users, the system, and the organization • Provide flexibility • Parameter, default • Data Considerations • Data should be entered into the system where and when it occurs because delays cause errors • Data should be verified when entered to catch errors immediately

37. Systems Design Guidelines • System Design Objectives • Data Considerations • Automated methods of data entry should be used whenever possible • Access for data entry should be controlled and all entries or changes to critical data values should be reported – audit trails • Every instance of entry and change to data should be logged • Data should be entered into a system only once • Data duplication should be avoided

38. Systems Design Guidelines • System Design Objectives • Architecture considerations • Use a modular design • Design modules that perform a single function are easier to understand, implement, and maintain

39. Prototyping • Prototyping produces an early, rapidly constructed working version of the proposed information system, called a prototype • Prototyping allows users to examine a model that accurately represents system outputs, inputs, interfaces, and processes

40. Prototyping • Prototyping Methods • System prototyping • Design prototyping • Throwaway prototyping

41. Prototyping • Prototyping Methods • Prototyping offers many benefits • Users and systems developers can avoid misunderstandings • Managers can evaluate a working model more effectively than a paper specification • Also consider potential problems • The rapid pace of development can create quality problems • In very complex systems, the prototype becomes unwieldy and difficult to manage

42. Prototyping • Limitations of Prototypes • A prototype is a functioning system, but it is less efficient than a fully developed system • Systems developers can upgrade the prototype into the final information system by adding the necessary capability • Otherwise, the prototype is discarded

43. Using Codes During System Design • Overview of Codes • Because codes often are used to represent data, you encounter them constantly in your everyday life • They save storage space and costs, reduce transmission time, and decrease data entry time • Can reduce data input errors

44. Using Codes During System Design • Types of Codes • Sequence codes • Block sequence codes • Alphabetic codes • Category codes • Abbreviation codes

45. Using Codes During System Design • Types of codes • Significant digit codes • Derivation codes • Cipher codes • Action codes • Self-checking codes

46. Using Codes During System Design • Developing a Code • Keep codes concise • Allow for expansion • Keep codes stable • Make codes unique • Use sortable codes • Avoid confusing codes

47. Using Codes During System Design • Developing a Code • Make codes meaningful • Use a code for a single purpose • Keep codes consistent

48. Chapter Summary • This chapter describes system development strategies, the preparation and presentation of the system requirements document, and the transition to the systems design phase of the SDLC • An important trend that views software as a service, rather than a product, has created new software acquisition options • Systems analysts must consider Web-based development environments

49. Chapter Summary • The systems analyst’s role in the software development process depends on the specific development strategy • The most important factor in choosing a development strategy is total cost of ownership (TCO) • The process of acquiring software involves a series of steps