Transition to System Design
5 likes4,956 views
This chapter discusses the transition from systems analysis to systems design. It covers selecting the best alternative design strategy by generating multiple design strategies and selecting the optimal one. The chapter also discusses software development options like in-house development, outsourcing, and purchasing off-the-shelf software. Prototyping is presented as an important part of the transition to allow users to evaluate a working model early in the design process.
Transition to System Design
- 1. 1
- 2. CHAPTER D2 TRANSION TO SYSTEM DESIGN ( Selecting the Best Alternative Design Strategy) 2
- 3. 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 ● Selecting the Best Alternative Design Strategy Learn to assemble the various pieces of an alternative design strategy. Learn how to generate at least three alternative design strategies. Discuss selecting the best design strategy using both qualitative and quantitative methods 3
- 4. Chapter Objectives Learn how to use the results of the analysis phase to update a Baseline Project Plan (BPP). * Describe software outsourcing options, including offshore outsourcing and the role of service providers Explain the transition from systems analysis to systems design, ● Explain the transition to systems design and the importance of prototyping ● Discuss guidelines for systems design 4
- 5. Alternative generation and selection ● Alternative generation and selection is the third major analysis activity. (Requirements determination, structuring requirements, alternatives generation and selection) ● During alternative generation and selection, the system’s structured requirements are transformed into several alternative design strategies, and the best way to acquire the new system is identified 5
- 6. Development Strategies Overview ● Selecting the best development path is an important decision that requires companies to consider three key topics – The impact of the Internet – Software outsourcing options – In-house software development alternatives 6
- 7. The Impact of the Internet ● The Internet has triggered enormous changes in business methods and operations, and software acquisition is no exception ● This section examines a trend that:- views software as a service, changing market-place for software, how Web-based development compares to traditional methods 7
- 8. The Impact of the Internet ● Software as a Service – The Software and Information Industry Association (SIIA) is an industry group that focuses on the digital economy – SIIA believes that the concept of software as a service is redefining the way that companies develop and deploy their information systems 8
- 9. The Impact of the Internet ● 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 and firms that offer Internet business services 9
- 10. The Impact of the Internet ● The Impact of the Internet on Systems Development – Developers will focus on Web-based application development, where the Web becomes an integral part of the application rather than just a communication channel • IBM’s WebSphere • Microsoft’s .NET 10
- 11. The Impact of the Internet ● The Impact of the Internet on Systems Development – Traditional development • Systems design is influenced by compatibility issues • Systems are designed to run on local and wide-area company networks • Web-based features are treated as enhancements rather than core elements of the design 11
- 12. The Impact of the Internet ● The Impact of the Internet on Systems Development – Web-based development • Systems are developed and delivered in an Internet- based framework such as .NET or WebSphere • Internet-based development treats the Web as the platform, rather than just a communication channel • Web-based software usually requires additional layers, called middleware 12
- 13. 13
- 14. Selecting the Best Alternative Design Strategy ● Two basic steps: 1. Generate a comprehensive set of alternative design strategies 2. Select the one design strategy that is most likely to result in the desired information system ● Process: 1. Divide requirements into different sets of capabilities 2. Enumerate different potential implementation environments that could be used to deliver the different sets of capabilities 3. Propose different ways to source or acquire the various sets of capabilities for the different 7.14 implementation environments 14
- 15. Selecting the Best Alternative Design Strategy(continued) ● Deliverables 1. At least three substantially different system design strategies for building the replacement information system 2. A design strategy judged most likely to lead to the most desirable information system 3. A Baseline Project Plan (BPP) for turning the most likely design strategy into a working information system 7.15 15
- 16. Generating Alternative Design Strategies ● Best to generate three alternatives: – Low-End • Provides all required functionality users demand with a system that is minimally different from the current system – High-End • Solves problem in question and provides many extra features users desire – Midrange • Compromise of features of high-end alternative with frugality of low-end alternative 7.16 16
- 17. Drawing Bounds on Alternative Designs ● Minimum Requirements – Mandatory features versus desired features – Forms of features • Data • Outputs • Analyses • User expectations on accessibility, response time, and turnaround time – Constraints on System Development: • Time • Financial • Elements of current system that cannot change • Legal • Dynamics of the problem 7.17 17
- 18. Criteria for Choosing Off-the-Shelf Software ● Cost – In-house versus purchased ● Functionality – Mandatory, essential, and desired features ● Vendor Support – Installation – Training – Technical support ● Viability of Vendor 7.18 18
- 19. Criteria for Choosing Off-the-Shelf Software (continued) ● Flexibility – Ease of customization ● Documentation – User documentation – Technical documentation ● Response Time ● Ease of Installation 7.19 19
- 20. 7.20 20
- 21. Validating Purchased Software Information ● Information from Vendor ● Software Evaluation Period ● Customer References from Vendor ● Independent Software Testing Service ● Trade Publications 7.21 21
- 22. Hardware and Software Issues Existing Platform New Hardware and System 1. Lower costs Software 2. Information system staff is 1. Some software familiar with operation and components will only run on new platform maintenance 2. Developing system for 3. Increased odds of new platform gives successfully integrating organization system with existing opportunity to upgrade applications technology holdings 4. No added costs of 3. New requirements may converting old systems to allow organization to new platform or radically change its transferring data computing operations 7.22 22
- 23. Hardware and Software Issues (continued) ● Request for Proposal (RFP) – A document provided to vendors to ask them to propose hardware and system software that will meet the requirements of your new system 7.23 23
- 24. Implementation Issues ● Technical and social aspects of implementation need to be addressed ● Training ● Disruption of Work 7.24 24
- 25. 25
- 26. Outsourcing ● The Growth of Outsourcing – Outsourcing has become part of an overall IT strategy for many organizations – On Demand – A firm that offers outsourcing solutions is called a service provider - Application service providers (ASP) – Internet business services (IBS) • Also called managed hosting 26
- 27. Outsourcing ● 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 to the application – A usage model or transaction model charges a variable fee based on the volume of transactions or operations performed by the application 27
- 28. Outsourcing ● 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 – Outsourcing also can affect day-to-day company operations and can raise some concerns – Outsourcing can be especially attractive to a company whose volume fluctuates widely, such as a defense contractor – Many firms are sending IT work overseas at an increasing rate (Offshore/global outsourcing) 28
- 29. 29
- 30. 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 30
- 31. Software Development Options ● Customizing a Software Package 1. You can purchase a basic package that vendors will customize to suit your needs 2. You can negotiate directly with the software vendor to make enhancements to meet your needs by paying for the changes 3. You can purchase the package and make your own modifications, if this is permissible under the terms of the software license 31
- 32. Software Development Options ● Creating User Applications – A user application utilizes standard business software – User interface – Help desk or information center (IC) – Screen generators – Report generators 32
- 33. Role of the Systems Analyst ● When selecting hardware and software, systems analysts often work as an evaluation and selection team ● The primary objective of the evaluation and selection team is to eliminate system alternatives that will not work, rank the system alternatives that will work, and present the viable alternatives to management for a final decision 33
- 34. Analyzing Cost and Benefits ● Financial Analysis Tools – Payback Analysis – Return on investment (ROI) – Net present value (NPV) 34
- 35. Analyzing Cost and Benefits ● Cost-Benefit Analysis Checklist – List each development strategy being considered – Identify all costs and benefits for each alternative. Be sure to indicate when costs will be incurred and benefits realized – Consider future growth and the need for scalability – Include support costs for hardware and software – Apply the financial analysis tools to each alternative – Study the results and prepare a report to management 35
- 36. 36
- 37. The Software Acquisition Process ● Step 1: Evaluate the Information System Requirements – Prepare a request for proposal or quotation • Request for proposal (RFP) • Evaluation model • Request for quotation (RFQ) 37
- 38. The Software Acquisition Process ● 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 system that contains thousands of forums, called newsgroups 38
- 39. The Software Acquisition Process ● Step 3: Evaluate the Alternatives – Existing users – Application testing – Benchmarking - benchmark – Match each package against the RFP features and rank the choices 39
- 40. The Software Acquisition Process ● 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 supplemental maintenance agreement 40
- 41. The Software Acquisition Process ● Step 5: Prepare a Recommendation – You should prepare a recommendation that evaluates and describes 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 41
- 42. The Software Acquisition Process ● 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 42
- 43. Completion of Systems Analysis Tasks ● Presentation to Management – Based on their decision, your next task will be one of the following 1. Implement an outsourcing alternative 2. Develop an in-house system 3. Purchase or customize a software package 4. Perform additional systems analysis work 5. Stop all further work 43
- 44. 44
- 45. The Transition to Systems 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 45
- 46. The Transition to Systems 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 46
- 47. 47
- 48. 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 – Systems design specification 48
- 49. Systems Design Guidelines ● Systems Design Objectives – The goal of systems design is to build a system that is effective, reliable, and maintainable 49
- 50. Systems Design Guidelines ● System Design Objectives – User Considerations – Data Considerations • Data should be entered into the system where and when it occurs because delays cause data errors • Data should be verified when entered to catch errors immediately • 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 50
- 51. Systems Design Guidelines ● System Design Objectives – Data Considerations • Data should be entered into a system only once • Data duplication should be avoided – Architecture considerations • Use a modular design • Design modules that perform a single function are easier to understand, implement, and maintain 51
- 52. Systems Design Guidelines ● Design Trade-Offs – Design goals often conflict with each other – Most design trade-off decisions that you will face come down to the basic conflict of quality versus cost – Avoid decisions that achieve short-term savings but might mean higher costs later 52
- 53. Prototyping ● Prototyping produces an early, rapidly constructed working version of the proposed information system, called a prototype ● Prototyping Methods – System prototyping – Design prototyping – Throwaway prototyping 53
- 54. 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 – Consider potential problems • The rapid pace of development can create quality problems • In very complex systems, the prototype becomes unwieldy and difficult to manage 54
- 55. Prototyping ● Prototyping Tools – Systems analysts can use powerful tools to develop prototypes • CASE tools • Application generators • Report generators • Screen generators • Fourth-generation language (4GL) • Fourth-generation environment 55
- 56. 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 ● Other Modeling Tools – Systems flowchart – American National Standards Institute (ANSI) 56
- 57. 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 57
- 58. Chapter Summary ● Identify requirements and constraints ● Generate alternative design strategies ● Select the best design strategy ● Update the Baseline Project Plan (BPP) 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 58
- 59. 59
- 60. Hoosier Burger’s New Inventory Control System ● Replacement for existing system ● Figure 7-4 ranks system requirements and constraints 7.60 60
- 61. 7.61 61
- 62. Hoosier Burger’s New Inventory Control System (continued) ● Figure 7-5 shows steps of current system ● When proposing alternatives, the requirements and constraints must be considered 7.62 62
- 63. 7.63 63
- 64. Hoosier Burger’s New Inventory Control System (continued) ● Figure 7-7 lists 3 alternatives: – Alternative A is a low-end proposal – Alternative C is a high-end proposal – Alternative B is a midrange proposal 7.64 64
- 65. Hoosier Burger’s New Inventory Control System (continued) ● Selecting the Most Likely Alternative – Weighted approach can be used to compare the three alternatives – Figure 7-8 shows a weighted approach for Hoosier Burger – Left-hand side of table contains decision criteria • Constants and requirements • Weights are arrived at by discussion with analysis team, users, and managers – Each requirement and constraint is ranked • 1 indicates that the alternative does not match the request well or that it violates the constraint • 5 indicates that the alternative meets or exceeds requirements or clearly abides by the constraint ● Selecting the Most Likely Alternative – According to the weights used, alternative C appears to be the 7.65 best choice 65
- 66. 7.66 66
- 67. Updating the Baseline Project Plan (BPP) ● The Baseline Project Plan (BPP) was developed during systems planning and selection phase ● Baseline Project Plan (BPP) can be used as an outline of a status report at analysis phase ● Schedule will be updated to reflect actual activities and durations ● An oral presentation of project status is typically made at this phase 7.67 67
- 68. PVF WebStore: Selecting the Best Alternative Design Strategy ● Requirements and constraints were compiled by consultant and team (see Table 7-4) 7.68 68
- 69. 7.69 69
- 70. PVF WebStore: Selecting the Best Alternative Design Strategy Proposed system is a scalable, three-tier approach Scalable The ability to seamlessly upgrade the system through either hardware upgrades, software upgrades or both Three-tier Web Server Provides connection to the Internet and presentation of HTML page Applications Server Middle layer of software and hardware that lies between Web server and corporate network Corporate network 7.70 Existing organizational computing infrastructure 70
- 71. 7.71 71
- 72. 72
- 73. WEB SEARCHES ● software acquisition alternatives, ● Selecting the Best Alternative Design Strategy ● software outsourcing options ● Analyzing Cost and Benefits – Financial Analysis Tools • Payback Analysis • Return on investment (ROI) • Net present value (NPV) • moodle.amriad.com • Imaginecup.com 73