SYSTEMS ANALYSIS DESIGN PHASE 2 SYSTEMS ANALYSIS Transition

SYSTEMS ANALYSIS & DESIGN PHASE 2 SYSTEMS ANALYSIS Transition to Systems Design

Chapter 6 Transition to Systems Design SYSTEMS ANALYSIS & DESIGN 4 E PHASE 2 2

Objectives PHASE 2 3 à Evaluate software alternatives and development strategies à Explain advantages and disadvantages of developing in-house software versus purchasing and customizing a software package à Describe how companies use out-sourcing and user applications SYSTEMS ANALYSIS & DESIGN 4 E

Objectives PHASE 2 4 à List the steps in purchasing and evaluating a software package à Explain the differences between a request for proposal (RFP) and a request for quotation (RFQ) à Describe the system requirements document and the presentation to management at the end of the systems analysis phase SYSTEMS ANALYSIS & DESIGN 4 E

Objectives PHASE 2 5 à Explain the transition from systems analysis to systems design, and the difference between logical and physical design à Explain the importance of prototyping and describe various prototyping methods, tools, and techniques SYSTEMS ANALYSIS & DESIGN 4 E

Objectives PHASE 2 6 à Discuss the systems design process and provide guidelines for system design à Create and use appropriate codes during systems design and development SYSTEMS ANALYSIS & DESIGN 4 E

Introduction PHASE 2 7 à Chapter 6 covers the remaining tasks in the systems analysis phase à Evaluation of alternative solutions à Preparation of the system requirements document à Presentation to management SYSTEMS ANALYSIS & DESIGN 4 E

Evaluating Software Alternatives PHASE 2 8 à 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 Click to see Figure 6 -1 à Vertical application Click to see Figure 6 -2 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -3

Evaluating Software Alternatives PHASE 2 9 à 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 SYSTEMS ANALYSIS & DESIGN 4 E

Evaluating Software Alternatives PHASE 2 10 à Purchasing a software package à Reasons for purchasing a software package à Lower costs à Less time to implement à Proven reliability and performance benchmarks à Less technical development staff à Future upgrades provided by the vendor à Other companies as resources SYSTEMS ANALYSIS & DESIGN 4 E

Evaluating Software Alternatives PHASE 2 11 à 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 SYSTEMS ANALYSIS & DESIGN 4 E

Evaluating Software Alternatives à Other software alternatives à Application service providers (ASP) à Outsourcing à End-user applications SYSTEMS ANALYSIS & DESIGN 4 E PHASE 2 12

Evaluating Software Alternatives PHASE 2 13 à Application service providers à Delivers applications by charging a usage or subscription fee à Service provided is called application hosting à Offer applications on a rental basis SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -4

Evaluating Software Alternatives PHASE 2 14 à Outsourcing à Using outside companies to handle portion of the workload, on short-term or longterm basis à Contract personnel firms à Systems management or facilities management firms SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -5

Evaluating Software Alternatives PHASE 2 15 à End-user systems à Utilizes standard business software à Can offer simple, low-cost solutions à Users can design their own data entry forms and reports SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -6

Evaluating Software Alternatives PHASE 2 16 à Selecting a software alternative à Decision will affect remaining SDLC phases à Systems analyst’s involvement depends on which alternative is selected SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -7

Steps in Evaluating and Purchasing Software Packages PHASE 2 17 à 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 SYSTEMS ANALYSIS & DESIGN 4 E

Steps in Evaluating and Purchasing Software Packages PHASE 2 18 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 Click to see Figure 6 -8 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -9

Steps in Evaluating and Purchasing Software Packages PHASE 2 19 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 or Web sites Click to see Figure 6 -10 à IT consultants à Newsgroups Click to see Figure 6 -11 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -12

Steps in Evaluating and Purchasing Software Packages PHASE 2 20 Step 3: evaluate software package alternatives à Object is to compare software packages and select the best alternative à Obtain information from many sources à Evaluation process à Obtain information from existing users à Test the application à Benchmark the package if necessary Click to see Figure 6 -13 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -14

Steps in Evaluating and Purchasing Software Packages Step 4: make the purchase à Software licenses à Lease agreements à Maintenance agreements SYSTEMS ANALYSIS & DESIGN 4 E PHASE 2 21

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 SYSTEMS ANALYSIS & DESIGN 4 E PHASE 2 22

Steps in Evaluating and Purchasing Software Packages PHASE 2 23 à Evaluation and selection teams à Objective of the process is to obtain the product with the lowest cost of ownership à Team approach ensures that critical factors are not overlooked and that a sound choice is made SYSTEMS ANALYSIS & DESIGN 4 E

Steps in Evaluating and Purchasing Software Packages PHASE 2 24 à Evaluation and selection teams à Primary objectives à Eliminate system alternatives that will not work à Rank the alternatives that will work à Present the viable alternatives to management for a final decision SYSTEMS ANALYSIS & DESIGN 4 E

Completion of Systems Analysis PHASE 2 25 à 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 SYSTEMS ANALYSIS & DESIGN 4 E

Completion of Systems Analysis PHASE 2 26 à 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 SYSTEMS ANALYSIS & DESIGN 4 E

Transition to Systems Design PHASE 2 27 à Essential to have an accurate and understandable system requirements document à Errors, omissions, and ambiguities will affect the quality of the finished product SYSTEMS ANALYSIS & DESIGN 4 E

Transition to Systems Design à Systems design overview à Logical design defines the functions and features of the system à Also know as the essential model à Physical design is a plan for the implementation of the system SYSTEMS ANALYSIS & DESIGN 4 E PHASE 2 28

Transition to Systems Design PHASE 2 29 à The relationship between analysis and design à Design phase cannot begin until analysis work is complete à Should return to the analysis phase only in very limited situations SYSTEMS ANALYSIS & DESIGN 4 E

Prototyping PHASE 2 30 à A prototype is an early, rapidly constructed working version of the system à A working model helps users understand the system à Can eliminate problems before the final version à Users can test-drive the model and either approve it or request changes à Intended only to validate user requirements and is discarded afterward SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -15

Prototyping PHASE 2 31 à Approaches to prototyping à System prototyping produces a full-featured, working model of the information system à Rapid application development (RAD) relies heavily on system prototyping à The RAD team defines, analyzes, designs, and tests prototypes SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -16

Prototyping PHASE 2 32 à Approaches to prototyping à Design prototyping, or throwaway prototyping, produces a user-approved design prototype that documents and benchmarks the features of the finished system à Design prototyping makes it possible to capture user input and approval while continuing to develop the system SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -17

Prototyping PHASE 2 33 à Approaches to prototyping à Benefits of prototyping à Users and developers can avoid misunderstandings à Developers can create accurate specifications à Managers can evaluate a working model à Analysts can use a prototype to develop testing and training procedures à Prototyping reduces the risk that occur when a finished system fails SYSTEMS ANALYSIS & DESIGN 4 E

Prototyping PHASE 2 34 à Approaches to prototyping à Potential problems of prototyping à Rapid pace of development can create quality problems à Other system requirements cannot adequately tested à Complex prototypes become unwieldy and difficult to manage SYSTEMS ANALYSIS & DESIGN 4 E

Prototyping PHASE 2 35 à Prototyping Tools à CASE tools à Application generators à Report generators à Screen generators à Fourth-generation languages (4 GLs) à Fourth-generation environment prototyping tools SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -18

Prototyping PHASE 2 36 à Prototyping Tools à Application generators à Also called code generators à Develops programs rapidly by translating a logical model directly into 4 GL code à Event driven languages specify actions that the program must perform when certain events occur à Nonprocedural languages does not require the programmer to write a series of instructions à Procedural language requires the programmer to create code for each processing step SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -19

Prototyping PHASE 2 37 à Prototyping Tools à Report generators à Also called a report writer à Designs formatted reports rapidly à Can create a mock-up report for reviewing before final design SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -20

PHASE 2 38 Prototyping à Prototyping Tools à Screen generators à Also called form generator à Interactive software tool à Helps design custom interface, create screen forms, and handle data entry procedures SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -21

Prototyping PHASE 2 39 à Limitations of prototypes à Less efficient than a fully developed system à Slower processing speeds and response times à May lack security requirements SYSTEMS ANALYSIS & DESIGN 4 E

Prototyping PHASE 2 40 à Other modeling 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 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -22

Overview of Systems Design PHASE 2 41 à Analysts must understand entire logical design before beginning physical design à Systems design steps à Review the system requirements à Design the system à Output à Input à Files and databases à System architecture à Present the systems design SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -23

Overview of Systems Design à Systems design objectives à Build a system that is: à Effective à Reliable à Maintainable SYSTEMS ANALYSIS & DESIGN 4 E PHASE 2 42

Overview of Systems Design PHASE 2 43 à Systems design considerations à User considerations à Make the system user-friendly à Consider where users receive output, or provide input to the system à Anticipate future needs àUsers àInformation system àOrganization à Must provide flexibility SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -24

Overview of Systems Design PHASE 2 44 à Systems design considerations à Data considerations à Enter data where and when it occurs à Verify data where it is input à Use automated data-entry methods à Control access for data entry à Report all entries or changes to critical values à Enter data into a system only once à Avoid data duplication SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -25

Overview of Systems Design à Systems design considerations à Processing considerations à Use a modular design à Design modules that perform a single function SYSTEMS ANALYSIS & DESIGN 4 E PHASE 2 45

Overview of Systems Design PHASE 2 46 à Design tradeoffs à Design goals often conflict with each other à Easier use might create more complex programming requirements à More flexibility might increase maintenance needed à Meeting one user’s requirements might make it harder to satisfy another’s needs à A major issue is quality versus cost SYSTEMS ANALYSIS & DESIGN 4 E

PHASE 2 47 Designing and Using Codes à A code is a set of letters or numbers that represents an item of data à Overview of codes à Codes serve many useful purposes à Save storage space and costs à Reduce data transmission time à Decrease data entry time à Can reveal or conceal information à Can reduce input errors SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -26

Designing and Using Codes PHASE 2 48 à Types of coding à Sequence codes à Block sequence codes à Alphabetic codes à Category codes à Abbreviation codes äMnemonic codes SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -27

Designing and Using Codes PHASE 2 49 à Types of Coding à Sequence codes à Block sequence codes à Alphabetic codes à Category codes à Abbreviation codes äMnemonic codes à Significant digit codes SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -28

Designing and Using Codes PHASE 2 50 à Types of coding à Sequence codes à Block sequence codes à Alphabetic codes à Category codes à Abbreviation codes äMnemonic codes à Significant digit codes à Derivation codes SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -29

Designing and Using Codes PHASE 2 51 à Types of coding à Sequence codes à Block sequence codes à Alphabetic codes à Category codes à Abbreviation codes ä Mnemonic codes à Significant digit codes à Derivation codes à Cipher codes à Action codes à Self-checking codes SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 6 -30

Designing and Using Codes à Developing a code à Keep codes concise à Allow for expansion à Keep codes stable à Makes codes unique à Use sortable codes à Avoid confusing codes à Make codes meaningful à Use a code for a single purpose à Keep codes consistent SYSTEMS ANALYSIS & DESIGN 4 E PHASE 2 52

SOFTWEAR, LIMITED PHASE 2 53 à Rick and Carla attend training workshop for SWL’s new CASE toolkit: Visible Analyst à Rick and Carla looked at various alternatives and potential solutions à 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 SYSTEMS ANALYSIS & DESIGN 4 E

PHASE 2 54 End Chapter 6 SYSTEMS ANALYSIS & DESIGN 4 E