Upload
damon-barnett
View
230
Download
0
Tags:
Embed Size (px)
Citation preview
11
Systems Analysis & Design(Sixth Edition)
Chapter 5Development Strategies
PHASE 2: SYSTEMS ANALYSIS
22
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 offshore outsourcing and the role of service providers
33
Chapter Objectives
Explain advantages and disadvantages of developing software in-house versus other alternatives
Explain cost-benefit analysis and financial analysis tools
Explain the differences between a request for proposal (RFP) and a request for quotation (RFQ)
44
Chapter Objectives
Describe the contents of the system requirements document
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 systems design
55
Introduction
Chapter 5 describes the remaining activities in the systems analysis phase
The chapter also describes the transition to systems design, prototyping, and systems design guidelines
66
Development Strategies Overview
Selecting the best development path is a key decision
Requires consideration of three key topics Impact of Internet Software outsourcing options In-house software development alternatives
77
The Impact of the Internet
Software as a Service Software and Information Industry Association (SIIA)
- an industry group focusing on digital economy Software as a service - redefining the way
companies develop and deploy information systems How do you think software as a service is
different from software as a product? How might the concept of software as a
service impact the software industry?
88
The Impact of the Internet
The Changing Software Marketplace Traditional S/W vendors develop and sell
application packages to customers New Marketplace traditional plus many forms of
outsourcing Application service providers Internet business services
99
The Impact of the Internet On Systems Development
As an analyst, consider: Traditional Environment Web-based Development Development
IBM’s WebSphere Microsoft’s .NET
1010
The Impact of the Internet On Systems Development
Traditional development Compatibility issues Networks Web-based features are treated as
enhancements Security less complex than Web
1111
The Impact of the Internet On Systems Development
Web-based development Internet-based framework
.NET or WebSphere Treats Web as platform Requires middleware Limited in-house involvement, if desired Can prevent illegal copying
1212
Outsourcing
Transfer of IS services for a fee Performed on a temporary or LT basis Services
Development Operation Maintenance
1313
Outsourcing
The Growth of Outsourcing Traditionally
to control costs dealing with rapid technological change
Today Traditional reasons still valid Part of overall IT strategy
On Demand
1414
Outsourcing
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
1515
Outsourcing
Outsourcing Fees Fixed Fee model A subscription model A usage model or transaction model
1616
Outsourcing
Outsourcing Issues and Concerns Mission-critical IT systems Day-to-day company operations Company whose volume fluctuates widely
1717
Outsourcing
In considering Outsourcing Check ASP’s History Advantages of Outsourcing Potential Risks of Outsourcing
1818
Outsourcing
Offshore Outsourcing Firms send IT work overseas at increasing rate Gartner predicts that by 2005 (in U.S.) …
1 in 10 IT jobs at IT companies will move offshore 1 in 20 IT jobs at non-IT companies will move offshore
1919
In-House Software Development Options
Make/Buy (Build/Buy) Decision Most important consideration is total cost of
ownership (TCO) Commercial software packages
2020
In-House Software Development Options
Make or Buy Decision Companies that develop software for sale are
called software vendors Value-added reseller (VAR) Horizontal application Vertical application
2121
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
2222
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
2424
In-House Software Development Options
Customizing a Software Package – 3 Ways Purchase and have vendor(s) customize Negotiate directly with software vendor to make
changes Purchase and make your own modifications
2525
In-House 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 Read-only properties
2626
Role of the Systems Analyst
Evaluation and Selection team Primary objective
Eliminate system alternatives that will not work Rank system alternatives that will work Present viable alternatives to management for final
decision
2727
Analyzing Cost and Benefits
Financial Analysis Tools Payback Analysis Return on investment (ROI) Net present value (NPV)
2828
Analyzing Cost and Benefits
Cost-Benefit Analysis Checklist List each development strategy being considered Identify all costs and benefits for each alternative
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
2929
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)
3030
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
3131
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
3232
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
3333
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
3434
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
3535
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
3636
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, the objectives of this presentation, and what decisions need to made
Summarize the primary viable alternatives. For each alternative, describe the costs, advantages, and disadvantages
3737
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
3838
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
3939
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
4040
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
4141
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
4242
Systems Design Guidelines
Systems Design Objectives The goal of systems design is to build a system that
is effective, reliable, and maintainable
4343
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
4444
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
4545
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
4646
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
4747
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
4848
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
4949
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)
5050
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