0% found this document useful (0 votes)
134 views35 pages

Development Strategies

1. The chapter discusses different development strategies like traditional development, web-based development, Software as a Service, and cloud computing. 2. It also covers outsourcing options like offshore outsourcing and different outsourcing fee models. 3. The software acquisition process involves evaluating requirements, identifying vendors, evaluating alternatives, performing cost-benefit analysis, making a recommendation, and implementing the solution.

Uploaded by

api-28115486
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
134 views35 pages

Development Strategies

1. The chapter discusses different development strategies like traditional development, web-based development, Software as a Service, and cloud computing. 2. It also covers outsourcing options like offshore outsourcing and different outsourcing fee models. 3. The software acquisition process involves evaluating requirements, identifying vendors, evaluating alternatives, performing cost-benefit analysis, making a recommendation, and implementing the solution.

Uploaded by

api-28115486
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd

Systems Analysis and

Design 8th Edition

Chapter 7
Development Strategies
The Impact of the Internet
• Software as a
Service
– Software as a
Service (SaaS)
– 25% of all new
business
software will
be deployed as
a service by
2011, while the
value of the
SaaS industry
will grow to 2
$40 billion
The Impact of the Internet
• Traditional vs. Web-Based Systems
Development
– Traditional development
• System design is influenced by
compatibility issues
• Systems are designed to run on local
and wide-area company networks
• Systems often utilize Internet links and
resources, but Web-based features
are treated as enhancements rather
than core elements of the design
3
The Impact of the Internet
• Traditional vs. Web-Based 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
4
The Impact of the Internet
• Looking to the
Future: Web 2.0
and Cloud
Computing
– The Web 2.0
platform will
enhance
interactive
experiences
including wikis
and blogs, and
social
networking
applications 5

What is Cloud Computing?
• [Link]
• The URL on the left
is an interesting
YouTube video
that explains
Cloud Computing

6
Outsourcing
• The Growth of
Outsourcing
– A firm that offers
outsourcing
solutions is
called a
service
provider
– Application
service
providers (ASP)
– Internet business
services (IBS) 7
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 operations8
performed by the application
Outsourcing
• Outsourcing Issues and Concerns
– Mission-critical IT systems should be
outsourced 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

9
Outsourcing
• Offshore Outsourcing
– Offshore outsourcing – global
outsourcing
– Many firms are sending IT work
overseas at an increasing rate
– The main reason for offshore
outsourcing is the same as domestic
outsourcing: lower bottom-line costs
– Offshore outsourcing, however,
involves some unique risks and
concerns 10
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

11
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
– 12
In-House Software
Development Options
• Customizing a Software Package
[Link] can purchase a basic package
that vendors will customize to suit
your needs
[Link] can negotiate directly with the
software vendor to make
enhancements to meet your needs
by paying for the changes
[Link] can purchase the package and
make your own modifications, if
this is permissible under the terms13
of the software license
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 meet requirements, rank
the system alternatives that are
feasible, and present the viable
alternatives to management for a
final decision
14
Analyzing Cost and Benefits
• Financial Analysis
Tools
– Payback Analysis
– Return on
investment
(ROI)
– Net present
value (NPV)

15
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 16
Analyzing Cost and Benefits
• Cost-Benefit Analysis Checklist
– Analyze various software licensing
options, including fixed fees and
formulas based on the number of
users or transactions
– Apply the financial analysis tools to
each alternative
– Study the results and prepare a report
to management

17
The Software Acquisition
Process
• 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
18
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 valuable resource is the
Internet bulletin board system that
contains thousands of forums, called
newsgroups

19
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

20
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

21
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
22
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
23
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 24
Completion of Systems
Analysis Tasks
• Presentation to Management
– Summarize the primary viable
alternatives
– 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 25
Completion of Systems
Analysis Tasks
• Presentation to Management
– Depending on their decision, your
next task as a systems analyst will
be one of the following
[Link] an outsourcing alternative
[Link] an in-house system
[Link] or customize a software
package
[Link] additional systems analysis
work
[Link] all further work
26
The Transition to Systems
Design
• Preparing for Systems Design Tasks
– It is essential to have an accurate and
understandable system
requirements document
• 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 27
Systems Design Guidelines
• The systems analyst must
understand the logical design of
the system before beginning the
physical design of any one
component
• Systems Design Objectives
– The goal of systems design is to build
a system that is effective, reliable,
and maintainable

28
Systems Design Guidelines
• Systems 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 –
hard-coded
• Provide flexibility
• Parameter, default

29
Systems Design Guidelines
• Systems Design Objectives
– Data Considerations
• Data should be entered into the
system where and when it occurs
because delays cause data errors
• Data should be verified when it is
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 trail
30
Systems Design Guidelines
• Systems Design
Objectives
– Data
Consideratio
ns
• Every
instance
of entry
and
change to
data
should be
logged 31
Systems Design Guidelines
• Systems Design Objectives
– Architecture considerations
• Use a modular design
• Design modules that perform a single
function are easier to understand,
implement, and maintain

32
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

33
Prototyping
• Prototyping
Methods
– System
prototyping
– Design
prototyping
– Throwaway
prototyping
– Prototyping
offers many
benefits
– Consider
potential 34
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

35

You might also like