C HAPTER 19
AIS Development Strategies
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
1 of 171
INTRODUCTION
• Questions to be addressed in this chapter include:
– How do organizations buy software, hardware, and
vendor services?
– How do information systems departments develop
custom software?
– How do end users develop, use and control
computer-based information systems?
– Why do organizations outsource their information
systems, and what are the benefits and risks of doing
so?
– How are prototypes used to develop an AIS, and what
are the advantages and disadvantages?
– What is computer-aided software engineering, and
how is it used in systems development?
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
2 of 171
INTRODUCTION
• Companies can experience a number of
difficulties in developing an AIS, including:
– Projects are backlogged for years because of the high
demand for resources.
– The newly designed system doesn’t meet user needs.
– The process takes so long that by the time it’s
complete, it’s obsolete.
– Users can’t adequately specify their needs.
– Changes to the AIS are often difficult to make after
requirements have been written into the
specifications.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
3 of 171
INTRODUCTION
• We’ll be discussing how to obtain a new
information system by:
– Purchasing prewritten software;
– Developing software in-house; or
– Outsourcing.
• We’ll also discuss how to hasten or improve the
development process through:
– Business process reengineering
– Prototyping
– Computer-aided software engineering (CASE) tools
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
4 of 171
INTRODUCTION
• We’ll be discussing how to obtain a new
information system by:
– Purchasing prewritten software
– Developing software in-house; or
– Outsourcing.
• We’ll also discuss how to hasten or improve the
development process through:
– Business process reengineering
– Prototyping
– Computer-aided software engineering (CASE) tools
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
5 of 171
PURCHASING PREWRITTEN SOFTWARE
• In the early days of computers,
companies were rarely able to buy
software to meet their needs.
• But commercially available packages
are now outpacing custom-developed
software as old systems are replaced.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
6 of 171
PURCHASING PREWRITTEN SOFTWARE
• Canned software is sold on the open
market to a broad range of users with
similar requirements.
– Some companies sell hardware and software
together as a package.
• These systems are called turnkey systems.
• Many are written by vendors who specialize in a
particular industry.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
7 of 171
PURCHASING PREWRITTEN SOFTWARE
– A major problem with canned software:
• It often does not meet all of a company’s
information needs.
• Can be overcome by modifying the canned
software.
– Usually best done by the vendor.
– Unauthorized modifications may render the
program unreliable and unstable.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
8 of 171
PURCHASING PREWRITTEN SOFTWARE
• Companies can also acquire software through
application service providers (ASPs).
– ASPs host web-based software and deliver it to
clients over the Internet.
– Companies don’t have to buy, install, or maintain
canned software; they simply “rent” it.
– If you used an online version of a package like TurboTax to prepare your taxes, that’s a consumer version
of renting software over the Internet.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
9 of 171
PURCHASING PREWRITTEN SOFTWARE
– Advantages of ASPs:
• Reduction of software costs and administrative
overhead.
• Automated software upgrades.
• Scalability as the business grows.
• Global access to information.
• Access to skilled IT personnel.
• Ability to focus on core financial competencies
rather than IT.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
10 of 171
PURCHASING PREWRITTEN SOFTWARE
• Purchasing Software and the SDLC:
– Companies that buy rather than develop
software still follow the SDLC process,
including:
• Systems analysis
 They conduct an initial investigation,
systems survey, and feasibility study, as
well as determining AIS requirements.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
11 of 171
PURCHASING PREWRITTEN SOFTWARE
• Purchasing Software and the SDLC:
– Companies that buy rather than develop
software still follow the SDLC process,
including:
• Systems analysis
• Conceptual design
• An important aspect is determining
whether software that meets AIS
requirements is already available.
• If so, a make-or-buy decision must be
made.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
12 of 171
PURCHASING PREWRITTEN SOFTWARE
• Purchasing Software and the SDLC:
– Companies that buy rather than develop
software still follow the SDLC process,
including:
• Systems analysis • If software is purchased,
program design and coding
• Conceptual design
can be omitted.
• Physical design • But software modifications
may be needed.
• Companies also may design
inputs, outputs, files, and
control procedures.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
13 of 171
PURCHASING PREWRITTEN SOFTWARE
• These activities must still take place,
including:
• Purchasing
Software
andpersonnel
the SDLC:
– Selecting
and training
– Installing
andrather
testingthan
hardware
and software
– Companies
that buy
develop
– Documenting procedures
software still follow the SDLC process,
– Converting from old to new AIS
including:
•
•
•
•
• However, the software modules do not
Systems
analysis
have
to be developed and tested.
Conceptual
• And design
the computer programs do not need
Physical
todesign
be documented.
Implementation and conversion
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
14 of 171
PURCHASING PREWRITTEN SOFTWARE
• Purchasing Software and the SDLC:
– Companies that buy rather than develop
software still follow the SDLC process,
including:
•
•
•
•
•
Systems analysis
Conceptual design
Physical design
Implementation and conversion
Operation and maintenance
• The AIS is operated like any other software.
• The vendor usually maintains the software.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
15 of 171
PURCHASING PREWRITTEN SOFTWARE
• Selecting a Vendor
– Deciding whether to make or buy software
can be made independently of the decision to
acquire hardware, service, maintenance, and
other AIS resources.
– And the preceding resources can be bought
independently of the software.
– But hardware and vendor decisions may
depend on the software decisions.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
16 of 171
PURCHASING PREWRITTEN SOFTWARE
• Vendors can be found by:
– Looking in phone book
– Obtaining referrals
– Scanning computer or trade magazines
– Attending conferences
– Using search organizations
• Beware of fly-by-night companies that can
leave your organization high and dry.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
17 of 171
PURCHASING PREWRITTEN SOFTWARE
• Acquiring Hardware and Software
– Once AIS requirements have been defined,
the organization can buy software and
hardware.
– Companies needing only a PC and some
office software can usually complete their own
research and make a selection.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
18 of 171
PURCHASING PREWRITTEN SOFTWARE
• When buying large or complex systems, a
request for proposal (RFP) should be
prepared:
– The RFP is an invitation to bidders to propose
a system by a specific date.
– Each proposal is evaluated.
– Finalists are investigated in depth.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
19 of 171
PURCHASING PREWRITTEN SOFTWARE
• The formal approach is important for
several reasons:
– Saves time
© 2006 Prentice Hall Business Publishing
• The same information is
provided to all bidders.
Accounting Information Systems, 10/e
Romney/Steinbart
20 of 171
PURCHASING PREWRITTEN SOFTWARE
• The formal approach is important for
several reasons:
– Saves time
– Simplifies the decision-making process
• The bidders all respond in the
same format and based on
the same information.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
21 of 171
PURCHASING PREWRITTEN SOFTWARE
• The formal approach is important for
several reasons:
– Saves time
– Simplifies the decision-making process
– Reduces errors • Less likely to look over
important factors in
evaluating proposals.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
22 of 171
PURCHASING PREWRITTEN SOFTWARE
• The formal approach is important for
several reasons:
– Saves time
– Simplifies the decision-making process
– Reduces errors
– Avoids potential for disagreement
• Both parties have the same
expectations and information
in writing.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
23 of 171
PURCHASING PREWRITTEN SOFTWARE
• When an RFP is solicited based on exact
hardware and software specifications:
– Total costs are usually lower.
– Less time is required for vendor preparation
and company evaluation.
– However, the vendor cannot recommend
alternatives.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
24 of 171
PURCHASING PREWRITTEN SOFTWARE
• A generalized RFP contains a problem
definition and requests a system that
meets specific performance objectives and
requirements.
– Leaves technical issues to the vendor.
– However, makes it more difficult to evaluate
proposals.
– May produce more costly bids.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
25 of 171
PURCHASING PREWRITTEN SOFTWARE
• Usually, the more information a company
provides to the vendors, the better their chances
of receiving a system that meets their
requirements.
– Detailed specifications should include:
•
•
•
•
•
Required applications
Inputs and outputs
Files and databases
Frequency and methods of file updating and inquiry
Unique characteristics or requirements
– Be sure to distinguish between mandatory and
desirable requirements.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
26 of 171
PURCHASING PREWRITTEN SOFTWARE
• Evaluating Proposals and Selecting a System
– Eliminate any proposals that:
• Are missing important information.
• Fail to meet minimum requirements.
• Are ambiguous.
– Those that pass the preliminary screening should be
compared with the proposed AIS requirements to
determine:
• If they meet all mandatory requirements.
• How many desirable requirements they meet.
– Finalists can be invited to demo their system using
company-supplied data.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
27 of 171
PURCHASING PREWRITTEN SOFTWARE
• In reviewing the proposals, you need to
evaluate:
– Hardware
– Software
– Vendors
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
28 of 171
PURCHASING PREWRITTEN SOFTWARE
• In reviewing the proposals, you need to
evaluate:
– Hardware
– Software
– Vendors
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
29 of 171
PURCHASING PREWRITTEN SOFTWARE
• Criteria to evaluate hardware include:
• Cost
• Ability to run required
software
• Processing speed and
capabilities
• Secondary storage
capability
• Input and output speeds
• Communication
capabilities
• Expandability
• Recency of technology
© 2006 Prentice Hall Business Publishing
• Availability
• Compatibility with existing
hardware, software, and
peripherals
• Performance compared to
competitors
• Cost and availability of
support and maintenance
• Warrantees and guarantees
• Financing arrangements
• Ability to meet mandatory
requirements
Accounting Information Systems, 10/e
Romney/Steinbart
30 of 171
PURCHASING PREWRITTEN SOFTWARE
• In reviewing the proposals, you need to
evaluate:
– Hardware
– Software
– Vendors
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
31 of 171
PURCHASING PREWRITTEN SOFTWARE
• Criteria to evaluate software include:
• Conformity with
specifications
• Need for modification
• Performance (speed,
accuracy, reliability)
• Use by other companies
• Satisfaction of other users
• Documentation
• Compatibility with existing
software
© 2006 Prentice Hall Business Publishing
• User-friendliness
• Ability to be demonstrated
and test-driven
• Warranties
• Flexibility and
maintainability
• Capability for online inquiry
of files and records
• Vendor upgrades
Accounting Information Systems, 10/e
Romney/Steinbart
32 of 171
PURCHASING PREWRITTEN SOFTWARE
• In reviewing the proposals, you need to
evaluate:
– Hardware
– Software
– Vendors
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
33 of 171
PURCHASING PREWRITTEN SOFTWARE
• Criteria to evaluate vendors include:
• Size
• Financial stability and
security
• Experience
• Quality of support and
warranties
• Regularity of updates
• Ability to provide financing
• Willingness to sign
contract
• Willingness to provide
references
© 2006 Prentice Hall Business Publishing
• Reputation for reliability
and dependability
• Hardware and software
support and maintenance
• Implementation and
installation support
• Quality and
responsiveness of
personnel
• Willingness to provide
training
• Responsiveness and
timeliness of support
Accounting Information Systems, 10/e
Romney/Steinbart
34 of 171
PURCHASING PREWRITTEN SOFTWARE
• Approaches to comparing system
performance:
– Benchmark problem
– Point scoring
– Requirements costing
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
35 of 171
PURCHASING PREWRITTEN SOFTWARE
• Approaches to comparing system
performance:
– Benchmark problem
– Point scoring
– Requirements costing
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
36 of 171
PURCHASING PREWRITTEN SOFTWARE
• Benchmark problem
– The new AIS performs a data processing task
with input, processing, and output jobs typical
of what would be required of the new system.
– Processing times are calculated and
compared.
– The AIS with the lowest time is judged most
efficient.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
37 of 171
PURCHASING PREWRITTEN SOFTWARE
• Approaches to comparing system
performance:
– Benchmark problem
– Point scoring
– Requirements costing
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
38 of 171
PURCHASING PREWRITTEN SOFTWARE
• Point scoring:
– A weight is assigned to each criterion used to
evaluate the system, based on the relative
importance of that criterion.
– Each criterion is rated for each product.
– Each rating is multiplied times the weight
assigned to the criterion to develop a
weighted score.
– The weighted scores are added for each
product.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
39 of 171
PURCHASING PREWRITTEN SOFTWARE
• EXAMPLE:
– Zorba Co. is evaluating systems offered by three
different vendors: Able Co., Baker Co., and Cook Co.
– Zorba has determined three criteria that they will use
to evaluate the different systems: cost, speed, and
vendor reliability.
– They have provided the following weights to each
criteria, with vendor reliability being the most critical:
• Vendor reliability—9
• Cost—6
• Speed—4
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
40 of 171
PURCHASING PREWRITTEN SOFTWARE
 Zorba examined the packages offered by the three
vendors and rated them based on these three criteria.
Ratings were from 1-5 with 5 being the highest score.
Criteria
Able Co.
Baker Co.
Cook Co.
Vendor reliability (9)
2
5
4
Cost (6)
5
3
4
Speed (4)
3
4
2
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
41 of 171
PURCHASING PREWRITTEN SOFTWARE
 The weighted scores are then computed by multiplying
the rating given to each vendor on each criterion times
the weight assigned to that criterion.
Criteria
Vendor reliability (9)
Able Co.
X
2
Baker Co.
Cook Co.
5
4
=
Cost (6)
5
3
4
Speed (4)
3
4
2
Able Co.
Baker Co.
Cook Co.
Vendor reliability (9)
18
45
36
Cost (6)
30
18
24
Speed (4)
12
16
8
WEIGHTED SCORES
Criteria
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
42 of 171
PURCHASING PREWRITTEN SOFTWARE
• The weighted scores for each company are
summed:
– Able = 60 points
– Baker = 79 points
– Cook = 68 points
• Based on the preceding scores, the bid would
probably be awarded to Baker Co.
WEIGHTED SCORES
Criteria
Able Co.
Baker Co.
Cook Co.
Vendor reliability (9)
18
45
36
Cost (6)
30
18
24
Speed (4)
12
16
8
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
43 of 171
PURCHASING PREWRITTEN SOFTWARE
• The preceding example is a simplification.
In a real-life scenario, several factors
would be different:
– There would probably be many more criteria
being considered.
– Several people would be rating the criteria,
and the final scores for each vendor would
probably be a composite of those individual
scores.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
44 of 171
PURCHASING PREWRITTEN SOFTWARE
• Approaches to comparing system
performance:
– Benchmark problem
– Point scoring
– Requirements costing
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
45 of 171
PURCHASING PREWRITTEN SOFTWARE
• Requirements costing:
– Estimates cost of purchasing or developing
features that are not included in a particular
AIS.
– The total AIS cost is calculated by adding the
acquisition cost to the purchasing and
development costs.
– Total cost = cost of system with all required
features.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
46 of 171
PURCHASING PREWRITTEN SOFTWARE
• To verify that the AIS that looks best on
paper is actually the best in practice:
– Test-drive the software.
– Contact other users for references.
– Evaluate vendor personnel.
– Confirm details of the proposal.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
47 of 171
INTRODUCTION
• We’ll be discussing how to obtain a new
information system by:
– Purchasing prewritten software
– Developing software in-house
– Outsourcing
• We’ll also discuss how to hasten or improve the
development process through:
– Business process reengineering
– Prototyping
– Computer-aided software engineering (CASE) tools
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
48 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Despite the availability of good canned
software, many organizations develop
their own because:
– Their requirements are unique; or
– Their size and complexity necessitates a
custom package.
• Developing custom software is difficult and
error prone and consumes much time and
resources.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
49 of 171
DEVELOPING SOFTWARE IN-HOUSE
• The most difficult hurdles:
– Lack of time.
– Complexity of desired system.
– Poor requirements and systems planning.
– Inadequate communication and cooperation
between departments and users.
– Lack of qualified staff.
– Poor senior executive support.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
50 of 171
DEVELOPING SOFTWARE IN-HOUSE
• After end users define their requirements,
the analysts:
– Work with the end users to determine the
format of paper and screen outputs.
– Identify:
• Data required for each input.
• Data to be retained in files.
– Develop detailed program specs to be
interpreted and coded by programmers.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
51 of 171
DEVELOPING SOFTWARE IN-HOUSE
• The process requires much discipline and
management supervision.
• Accountants may help as project
supervisors, users, or development team
members.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
52 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Custom software is usually developed and
written in-house.
– Alternately, organizations may engage an
outside company to develop a package or
assemble one from their inventory of
modules.
– These modules are adapted, combined, and
organized to form a customized product that
meets specific requirements.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
53 of 171
DEVELOPING SOFTWARE IN-HOUSE
• When contracting with an outside organization,
maintain control over development and observe
the following guidelines:
– Carefully select a developer
• Look for:
– Experience in the industry
– A good understanding of:
• Business in general
• How your company
conducts business
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
54 of 171
DEVELOPING SOFTWARE IN-HOUSE
• When contracting with an outside organization,
maintain control over development and observe
the following guidelines:
– Carefully select a developer
– Sign a contract to clearly define responsibilities
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
55 of 171
DEVELOPING SOFTWARE IN-HOUSE
• When contracting with an outside organization,
maintain control over development and observe
the following guidelines:
– Carefully select a developer
– Sign a contract to clearly define responsibilities
– Plan and monitor each step
• Design all aspects in detail.
• Include frequent checkpoints.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
56 of 171
DEVELOPING SOFTWARE IN-HOUSE
• When contracting with an outside organization,
maintain control over development and observe
the following guidelines:
–
–
–
–
Carefully select a developer
Sign a contract to clearly define responsibilities
Plan and monitor each step
Maintain effective and frequent communication
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
57 of 171
DEVELOPING SOFTWARE IN-HOUSE
• When contracting with an outside organization,
maintain control over development and observe
the following guidelines:
–
–
–
–
–
Carefully select a developer
Sign a contract to clearly define responsibilities
Plan and monitor each step
Maintain effective and frequent communication
Control all costs
• Cash outflows should be minimized until
the project is completed and accepted.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
58 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Information systems consultants suggest that
clients develop their own software only if it
provides a significant competitive advantage.
– Payroll and A/R systems are not good candidates for
in-house development.
– There might be significant benefits to developing
sophisticated product manufacturing software.
• If there is no significant competitive advantage,
buy software from an outside supplier.
– Trend appears to be in that direction.
• There is no pat answer to the make-or-buy
decision.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
59 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Another approach to developing software
in-house is to take the lion’s share of the
effort out of the hands of the IS
department and place it in the laps of the
ultimate information users.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
60 of 171
DEVELOPING SOFTWARE IN-HOUSE
• End-User Developed Software
– End-user computing (EUC) is the hands-on
development, use, and control of computer-based
information systems by users.
– With EUC, individuals use IT to meet their own IS
needs rather than rely on systems professionals.
– Why?
• The demand for information systems has grown
exponentially since the introduction of the computer.
• One solution to meeting these needs is to have end users
meet their own information needs.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
61 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Technology has evolved to automate much
of the system development process.
Factors contributing to EUC are:
– Increased computer literacy.
– Easier-to-use programming languages.
– Inexpensive PCs.
– A variety of powerful and inexpensive
software packages.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
62 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Consequently, users have begun to
develop their own systems to:
– Create and store data.
– Access and download company data.
– Share data and computer resources in
networks.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
63 of 171
DEVELOPING SOFTWARE IN-HOUSE
• As end users began to meet their initial
needs, two things happened:
– Users realized computers could be used to
meet more and more information needs.
– Increased access to data created many new
uses and needs for information.
• Result: A tremendous growth in end-user
computing that is expected to continue.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
64 of 171
DEVELOPING SOFTWARE IN-HOUSE
• EUC has altered the role of the IS staff:
– They continue to develop and maintain transaction
processing systems and company-wide databases
from which end users draw information.
– They provide users with technical advice and
operational support and make as much information
available to them as possible.
– While the support work has increased for the IS staff,
this work is counter-balanced by a decreased
demand for traditional IS services.
– EUC may make up 75-95% of all IS processing by
2010.
• Because accountants will be end users, they
need an understanding of EUC concepts.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
65 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Appropriate End-User Development
and Use
– End user development (EUD) happens when
information users (e.g., managers,
accountants, auditors) develop their own
applications using computer specialists as
advisors.
• Inappropriate for complex systems.
• Not used for large-scale processing, such as
payroll, receivables, payables, general ledger, or
inventory.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
66 of 171
DEVELOPING SOFTWARE IN-HOUSE
– End user development may be most
appropriate for:
• Retrieving info from company databases to
produce simple reports or answer single queries.
• Performing “what if,” sensitivity, or statistical
analyses.
• Developing applications that use prewritten
software (e.g., spreadsheet or database software).
• Preparing schedules (such as aging of accounts)
and lists.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
67 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Benefits of end-user computing:
– User creation, control, and implementation
• Users control the development process, decide
what info needs are important, and if a system
should be developed.
• Ownership helps them build better systems.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
68 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Benefits of end-user computing:
– User creation, control, and implementation
– Systems that meet user needs
• Because users discover flaws that systems people
would not catch.
• Also, the communication problem between user 
analyst  programmer are avoided.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
69 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Benefits of end-user computing:
– User creation, control, and implementation
– Systems that meet user needs
– Timeliness
 Much of the expensive and time-consuming costbenefit analysis, requirements definitions, and red
tape are reduced.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
70 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Benefits of end-user computing:
– User creation, control, and implementation
– Systems that meet user needs
– Timeliness
– Freeing up systems resources
• The IS department can exert time and resources on
other information and maintenance activities.
• Reduces both visible and invisible backlog of
systems development projects.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
71 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Benefits of end-user computing:
– User creation, control, and implementation
– Systems that meet user needs
– Timeliness
– Freeing up systems resources
– Versatility and ease of use
• Most EUC software is easy to understand and use.
• With a laptop, the work can be done at home or
almost anywhere.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
72 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Risks of end-user computing:
– Logic and development errors
• End users are inexperienced in systems development.
• Consequently, they are more likely to make errors and less
likely to recognize them.
• They may:
–
–
–
–
–
Solve wrong problem
Poorly define systems requirements
Apply inappropriate analytical methods
Use wrong software
Use incomplete or outdated information
• Errors are often caused by faulty logic, formulas, or software
commands.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
73 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Risks of end-user computing:
– Logic and development errors
– Inadequately tested applications
• Users probably won’t test rigorously.
• They tend not to recognize the need for testing, the difficulty, or
the time involved.
• Tend to have grossly inflated opinions of how error-free their
systems are.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
74 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Risks of end-user computing:
– Logic and development errors
– Inadequately tested applications
– Inefficient systems
• They get the job done but aren’t always efficient.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
75 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Risks of end-user computing:
– Logic and development errors
– Inadequately tested applications
– Inefficient systems
– Poorly controlled and documented
systems
• Many end users don’t implement controls to
protect their system
• Systems are often poorly documented because
they think it’s unimportant
• They fail to realize that others cannot understand
the system without documentation.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
76 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Risks of end-user computing:
– Logic and development errors
– Inadequately tested applications
– Inefficient systems
– Poorly controlled and documented systems
– System incompatibilities
• Some companies add end-user equipment without
considering the technological implications.
• May end up with a diversity of hardware and
software that is difficult to support or network.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
77 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Risks of end-user computing:
– Logic and development errors
– Inadequately tested applications
– Inefficient
• If systems
end users aren’t aware that others have similar
information needs, duplication occurs.
– Poorly controlled
and documented systems
• Inexperienced users may also bite off more than
– System incompatibilities
they can chew, wasting time and resources.
– Duplication of systems and data and
wasted resources
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
78 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Risks of end-user computing:
– Logic and development errors
– Inadequately tested applications
• Buying
PCs for multitudes of workers is costly.
– Inefficient
systems
• Regular updating of hardware and software is also
– Poorly controlled
expensive. and documented systems
• EUC
also increases costs if it diverts users from
– System
incompatibilities
their primary jobs.
– Duplication
and data
and
wasted
• EUC of
cansystems
increase demands
on the
company
mainframe and IS staff for support.
resources
– Increased costs
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
79 of 171
DEVELOPING SOFTWARE IN-HOUSE
• To achieve proper balance between
maximizing the benefits of end user
systems and minimizing the risks:
– Systems analysts can act as advisers and
require user-created systems to be reviewed
and documented prior to use.
– Users can be trained in systems analysis so
they can identify and adequately meet their
needs, as well as reviewing the work of
others.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
80 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Organizations use several approaches to
managing and controlling EUC.
– If you give the systems department control over EUC:
• Growth of EUC is discouraged
• The organization is denied most of its benefits
• It’s not in the company’s best long-term interests.
– However, if there are no controls over the tools that
can be purchased or how they can be used:
• Chaos can result
• The system can be difficult to support
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
81 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Best to provide enough guidance and
support to adequately control the system
but allow users flexibility.
• A help desk can encourage, support,
coordinate, and control end-user activities.
– One level of help desk employees might be
trained with scripted answers.
– A higher level might handle more complicated
issues.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
82 of 171
DEVELOPING SOFTWARE IN-HOUSE
• Help desk duties include:
– Providing hotline assistance to solve problems.
– Serving as a clearinghouse for information, coordination,
and assistance.
– Training end users how to use specific hardware and
software, and providing technical maintenance and
support.
– Evaluating new end-user hardware and software products.
– Assisting with application development.
– Developing and implementing standards for:
• Hardware and software purchases to ensure compatibility.
• Documentation and application testing.
• Overseeing security issues such as fraud, software piracy,
and viruses.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
83 of 171
INTRODUCTION
• We’ll be discussing how to obtain a new
information system by:
– Purchasing prewritten software
– Developing software in-house
– Outsourcing
• We’ll also discuss how to hasten or improve the
development process through:
– Business process reengineering
– Prototyping
– Computer-aided software engineering (CASE) tools
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
84 of 171
OUTSOURCE THE SYSTEM
• Outsourcing is hiring an outside company
to handle all or part of an organization’s
data processing activities.
– In a mainframe outsourcing agreement:
• The outsourcers buy the client’s computers and
hire all or most of the client’s employees.
• Then operate and manage the entire system on
the client’s site or migrate it to the outsourcer’s
computers.
• Many of these contracts have terms of 10 or more
years and cost from hundreds of thousands to
millions of dollars a year.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
85 of 171
OUTSOURCE THE SYSTEM
– In a client/server or a PC outsourcing
agreement the organization outsources:
•
•
•
•
A particular service (e.g., help desk services);
A segment of its business
A particular function; or
PC support.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
86 of 171
OUTSOURCE THE SYSTEM
• Examples of outsourced activities:
– Installation
– Training
– Maintenance
– Help desk
– Technical support
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
87 of 171
OUTSOURCE THE SYSTEM
• The Growth in Outsourcing
Applications
– Outsourcing was initially used for
standardized applications such as payroll,
accounting, and purchasing.
– Also used by companies that were struggling
to survive and wanted a quick cash infusion
from selling their hardware.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
88 of 171
OUTSOURCE THE SYSTEM
• Kodak and Xerox were very successful at
cutting capital expenditures and other
costs, which motivated others to outsource
their systems.
• Now many Fortune 500 companies
outsource some or all of there IS.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
89 of 171
OUTSOURCE THE SYSTEM
• Most companies that outsource use
several different companies rather than a
single source in order to:
– Increase flexibility
– Foster competition
– Reduce costs
• Most companies do not outsource:
– Strategic management of their IT environment
– Business process management
– IT architecture
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
90 of 171
OUTSOURCE THE SYSTEM
• Benefits of outsourcing:
– Provides a business solution
• Allows companies to concentrate on their core
competencies.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
91 of 171
OUTSOURCE THE SYSTEM
• Benefits of outsourcing:
– Provides a business solution
– Asset utilization
• Companies can improve cash position and reduce
expenses by selling their computers to an
outsourcer.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
92 of 171
OUTSOURCE THE SYSTEM
• Benefits of outsourcing:
– Provides a business solution
– Asset utilization
– Access to greater experience and more
advanced technology
• The cost and time to stay at the cutting edge of
technology is escalating rapidly.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
93 of 171
OUTSOURCE
SYSTEM
• OutsourcingTHE
can reduce
IS costs by 15-30
• Benefits
percent.
• Outsourcers can pass along savings
of outsourcing:
from:
– Provides a –business
solution
Standardizing
applications
– Buying hardware at bulk prices
– Asset utilization
– Splitting development and maintenance costs
– Access to greater
experience
and more
between
projects
– Operating at higher volumes
advanced technology
– Lower costs
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
94 of 171
OUTSOURCE THE SYSTEM
• Benefits of outsourcing:
– Provides a business solution
– Asset utilization
– Access to greater experience and more
advanced technology
– Lower costs
– Improved development time
• Experienced specialists can often develop and
implement a system faster and more efficiently.
• Can also help the company cut through some of
the internal politics.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
95 of 171
OUTSOURCE THE SYSTEM
• Benefits of outsourcing:
– Provides a business solution
– Asset utilization
– Access to greater experience and more
advanced technology
• Companies with seasonal fluctuations don’t have
– Lower costs
to staff an IT force or maintain hardware for peak
– Improvedperiods.
development time
– Elimination of peaks-and-valleys usage
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
96 of 171
OUTSOURCE THE SYSTEM
• Benefits of outsourcing:
– Provides a business solution
– Asset utilization
– Access to greater experience and more
advanced technology
– Lower costs
• Companies
with in-house
– Improved
development
time systems that downsize
are often left with an unnecessarily large AIS
function.
– Elimination
of peaks-and-valleys usage
– Facilitation of downsizing
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
97 of 171
OUTSOURCE THE SYSTEM
• Risks of outsourcing:
– Inflexibility
• Many outsourcing contracts are for 10 years.
• If the company is dissatisfied, has problems, or
goes through extensive structural changes, the
contract is difficult and/or costly to break.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
98 of 171
OUTSOURCE THE SYSTEM
• Risks of outsourcing:
– Inflexibility
– Loss of control
• The company may lose control of its system and data.
• Also risk of confidential data being shared with others.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
99 of 171
OUTSOURCE THE SYSTEM
• Risks of outsourcing:
– Inflexibility
– Loss of control
– Reduced competitive advantage
• Companies can lose a fundamental understanding of
their IS needs and how the system can provide it with
competitive advantages.
• Outsourcers are not as motivated to meet the client’s
competitive challenges.
• Can be mitigated significantly by outsourcing the
portion of business processes considered standard
(e.g., payroll, accounts receivable) and customizing the
portion that provides competitive advantage.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
100 of 171
OUTSOURCE THE SYSTEM
• Risks of outsourcing:
– Inflexibility
– Loss of control
– Reduced competitive advantage
– Locked in system
• It is expensive and difficult to reverse outsourcing.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
101 of 171
OUTSOURCE THE SYSTEM
• Risks of outsourcing:
– Inflexibility
– Loss of control
– Reduced competitive advantage
– Locked in system
– Unfulfilled goals
• Many outsourcing goals and benefits are never realized.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
102 of 171
OUTSOURCE THE SYSTEM
• Risks of outsourcing:
– Inflexibility
– Loss
of control
• Some
companies complain of poor service from
their outsourcers,
– Reduced
competitive particularly
advantagewith respect to:
– Slow or no responsiveness to changing business
– Lockedconditions.
in system
– Poorly
planned migration to new technologies.
– Unfulfilled
goals
– Poor service
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
103 of 171
INTRODUCTION
• We’ll be discussing how to obtain a new
information system by:
– Purchasing prewritten software
– Developing software in-house
– Outsourcing
• We’ll also discuss how to hasten or improve the
development process through:
– Business process reengineering
– Prototyping
– Computer-aided software engineering (CASE) tools
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
104 of 171
BUSINESS PROCESS REENGINEERING
• Business process reengineering (BPR) is
the analysis and redesign of business
processes and information systems to
achieve significant performance
improvements.
– Reduces a company to its essential business
processes
– Reshapes organizational work practices and
information flows to take advantage of
technological advancements.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
105 of 171
BUSINESS PROCESS REENGINEERING
• BPR:
– Simplifies the system.
– Makes it more effective.
– Improves a company’s quality and service.
• BPR software has been developed to help
automate many BPR tasks
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
106 of 171
BUSINESS PROCESS REENGINEERING
• Michael Hammer has set forth several principles
that help organizations successfully reengineer
business processes:
- Organize around outcomes, not tasks.
• DO AWAY WITH: Assigning different parts of a business
process to different people, with the resulting handoffs,
delays, and errors.
• INSTEAD: Each person’s job is designed around an
objective, outcome, or process rather than a task needed
to complete a process.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
107 of 171
BUSINESS PROCESS REENGINEERING
• Michael Hammer has set forth several principles
that help organizations successfully reengineer
business processes:
- Organize around outcomes, not tasks.
- Require those who use the output to perform the
process.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
108 of 171
BUSINESS PROCESS REENGINEERING
 Michael Hammer has set forth several principles
that help organizations successfully reengineer
business processes:
- Organize around outcomes, not tasks.
- Require those who use the output to perform the
process.
- Require those who produce information to
process it.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
109 of 171
BUSINESS PROCESS REENGINEERING
• You centralize operations to achieve economies
of scale and eliminate redundancy.
• Michael Hammer has set forth several principles
• You decentralize operations to be more
that help
organizations successfully reengineer
responsive to customers and provide better
business
processes:
service
- Organize
around outcomes,
not tasks.
• With technology,
you don’t
have to choose
- Require
those who use
the output
to perform
– Corporate-wide
databases
centralize
data the
process.
– Telecommunications technology disburses it to the
organization.
- Require
those who produce information to process it.
- Centralize AND disperse data.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
110 of 171
BUSINESS PROCESS REENGINEERING
• Michael Hammer has set forth several principles
that help organizations successfully reengineer
business processes:
- Organize around outcomes, not tasks.
- Require
those who use the output to perform the
 Example: In developing a new product, include on the
process.
development team at least one person from each involved
department,
theproduce
right hand
will know what
the left hand
- Require
those so
who
information
to process
it.
is doing and the process will be smoothly integrated.
- Centralize AND disperse data.
- Integrate parallel activities.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
111 of 171
BUSINESS PROCESS REENGINEERING
• Michael Hammer has set forth several principles
that help organizations successfully reengineer
• In a traditional
system, there is a layer of worker
business
processes:
-
bees and several layers of manager bees,
Organize
not tasks.
auditoraround
bees, outcomes,
and controller
bees.
Require
those who usesystem,
the output
perform
the do the
• In a reengineered
thetopeople
who
process.
work have decision-making responsibility.
Require
those who
produceenables
information
to process it.
– Information
technology
their decision
accuracy.
Centralize
AND disperse data.
– Controls are built into the process itself.
Integrate
parallel activities.
Empower workers, use built-in controls, and
flatten the organization chart.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
112 of 171
BUSINESS PROCESS REENGINEERING
• Michael Hammer has set forth several principles
that help organizations successfully reengineer
business processes:
- Organize around outcomes, not tasks.
- Require those who use the output to perform the
process.
- Require those who produce information to process it.
- Centralize
disperse
• InsteadAND
of having
eachdata.
functional area running its own AIS
- Integrate
parallelthe
activities.
and entering
same data, use source data automation,
EDI, etc.
to capture
electronically
the flatten
source and
- Empower
workers,
usedata
built-in
controls,atand
disburse it tochart.
where it needs to be used.
the organization
- Capture data once—at its source.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
113 of 171
BUSINESS PROCESS REENGINEERING
• Underlying reengineering is the efficient
and effective use of the latest information
technology, e.g.:
– Radio- and satellite-based communications
– Powerful handheld computers
– Image processing that lets multiple users
handle a document simultaneously.
– Active documents.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
114 of 171
BUSINESS PROCESS REENGINEERING
• Challenges Faced by Reengineering Efforts:
– Many BPR efforts fail or fall short of their objectives.
A company must overcome the following obstacles:
• Tradition
• “We’ve always done it this way!”
• Success requires changes in culture and beliefs.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
115 of 171
BUSINESS PROCESS REENGINEERING
• Challenges Faced by Reengineering Efforts:
– Many BPR efforts fail or fall short of their objectives.
A company must overcome the following obstacles:
• Tradition
• Resistance
• Change is always met with resistance.
• Requires continual reassurance, persuasion, and
support.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
116 of 171
BUSINESS PROCESS REENGINEERING
• Challenges Faced by Reengineering Efforts:
– Many BPR efforts fail or fall short of their objectives.
A company must overcome the following obstacles:
• Tradition
• Resistance
• Time and cost requirements
• Two or more years are required to complete BPR.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
117 of 171
BUSINESS PROCESS REENGINEERING
• Challenges Faced by Reengineering Efforts:
– Many BPR efforts fail or fall short of their objectives.
A company must overcome the following obstacles:
•
•
•
•
Tradition
Resistance
Time and cost requirements
Lack of management support
• Managers are nervous about the “big hype--few
results” syndrome.
• Without their support, the effort will fail.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
118 of 171
BUSINESS PROCESS REENGINEERING
• Challenges Faced by Reengineering Efforts:
– Many BPR efforts fail or fall short of their objectives.
A company must overcome the following obstacles:
•
•
•
•
•
Tradition
Resistance
Time and cost requirements
Lack of management support
Skepticism
• BPR is sometimes viewed as just the same picture
in a different frame.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
119 of 171
BUSINESS PROCESS REENGINEERING
• Challenges Faced by Reengineering Efforts:
– Many BPR efforts fail or fall short of their objectives.
A company must overcome the following obstacles:
•
•
•
•
•
•
Tradition
Resistance
Time and cost requirements
Lack of management support
Skepticism
Retraining
• The necessary retraining costs time and dollars.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
120 of 171
BUSINESS PROCESS REENGINEERING
• Challenges Faced by Reengineering Efforts:
– Many BPR efforts fail or fall short of their objectives.
A company must overcome the following obstacles:
•
•
•
•
•
•
•
Tradition
Resistance
Time and cost requirements
Lack of management support
Skepticism
Retraining
Controls
• Cannot skip the inclusion of controls to ensure
reliability and integrity.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
121 of 171
INTRODUCTION
• We’ll be discussing how to obtain a new
information system by:
– Purchasing prewritten software
– Developing software in-house
– Outsourcing
• We’ll also discuss how to hasten or improve the
development process through:
– Business process reengineering
– Prototyping
– Computer-aided software engineering (CASE) tools
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
122 of 171
PROTOTYPING
• Prototyping is an approach to systems design in
which a simplified working model of a system is
developed.
– The prototype (first draft) is built quickly at low cost
and provided to users for experimentation.
– Playing with the prototype allows users to determine
what they do and do not like.
– Developers modify the system in response to user
comments and re-present it to them.
– The iterative process continues until users are
satisfied that the system meets their needs.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
123 of 171
PROTOTYPING
• The basic premise is that it’s easier for
people to express what they like or dislike
than to imagine what they want in a
system.
– In another words, it helps to have a straw man
to aim at.
– Even a simple system that is not fully
functional demonstrates features far better
than graphics and verbiage.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
124 of 171
PROTOTYPING
• Developers who use prototyping still go through
the systems development life cycle.
• But prototyping allows them to expedite some
analysis and design.
• For example, prototyping captures user needs
and helps developers and users make many
conceptual and physical design decisions.
• Current practice leans heavily toward
prototyping so that projects can be completed
quickly.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
125 of 171
PROTOTYPING
• Four steps are involved in developing a
prototype:
– STEP ONE: Identify basic requirements
– STEP TWO: Develop an initial prototype
– STEP THREE: Repeated iterations
– STEP FOUR: Use the system
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
126 of 171
PROTOTYPING
• Four steps are involved in developing a
prototype:
– STEP ONE: Identify basic requirements
– STEP TWO: Develop an initial prototype
– STEP THREE: Repeated iterations
– STEP FOUR: Use the system
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
127 of 171
PROTOTYPING
• The first step is to identify basic
requirements by meeting with users to
agree on the size and scope of the system
and decide what it should include and
exclude.
– Developer and users also determine:
• Decision-making and transaction processing
outputs.
• Inputs and data needed to produce those outputs.
– The emphasis is on what outputs should be
produced rather than how.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
128 of 171
PROTOTYPING
– The developer must ensure:
• User expectations are realistic
• Their basic information requirements are met.
– The designer uses the information
requirements to develop cost, time, and
feasibility estimates for alternative AIS
solutions.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
129 of 171
PROTOTYPING
• Four steps are involved in developing a
prototype:
– STEP ONE: Identify basic requirements
– STEP TWO: Develop an initial prototype
– STEP THREE: Repeated iterations
– STEP FOUR: Use the system
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
130 of 171
PROTOTYPING
• The second step involves developing an
initial prototype that meets the agreed-on
requirements.
– Emphasize speed and low cost rather than
efficiency of operation.
– The goal is to implement the prototype within
a short time period.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
131 of 171
PROTOTYPING
• Because of time constraints, some
aspects are sacrificed. For example, at
this point, you ignore:
– Nonessential functions
– System controls
– Exception handling
– Validation of input data
– Processing speed
– Efficiency considerations
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
132 of 171
PROTOTYPING
• Users must see and use tentative versions of:
–
–
–
–
Data entry display screens
Menus
Input prompts
Source documents
• They must also:
–
–
–
–
Respond to prompts
Query the system
Judge response times
Issue commands
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
133 of 171
PROTOTYPING
• When the prototype is finished, the
developer returns to the users and
demonstrates the system.
• Users are instructed to:
– Experiment.
– Comment on what they do and do not like.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
134 of 171
PROTOTYPING
• Four steps are involved in developing a
prototype:
– STEP ONE: Identify basic requirements
– STEP TWO: Develop an initial prototype
– STEP THREE: Repeated iterations
– STEP FOUR: Use the system
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
135 of 171
PROTOTYPING
• The third step involves repeated iterations
of:
– Users identifying changes.
– Developers making the changes.
– The system being turned back to users for
next round.
• This step continues until users are
satisfied—usually 4-6 iterations.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
136 of 171
PROTOTYPING
• Four steps are involved in developing a
prototype:
– STEP ONE: Identify basic requirements
– STEP TWO: Develop an initial prototype
– STEP THREE: Repeated iterations
– STEP FOUR: Use the system
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
137 of 171
PROTOTYPING
• The final step involves using the system
approved by the users.
• An approved prototype is typically used in
one of two ways.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
138 of 171
PROTOTYPING
• Half of the prototypes are turned into fully
functional systems referred to as
operational prototypes.
– To make them operational, the developer
must:
•
•
•
•
Add needed controls.
Improve operational efficiency.
Provide backup and recovery.
Integrate the prototype with the systems with which
it interfaces.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
139 of 171
PROTOTYPING
• Changes may be necessary to allow the
program to:
– Accept real input.
– Access real data files.
– Process data.
– Make necessary computations and
calculations.
– Produce real output.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
140 of 171
PROTOTYPING
• When it’s not practical to modify the
prototype to make a fully functional
system, non-operational or throwaway
prototypes can be used in several ways:
– They may be discarded, and the systems
requirements identified in the process of
building them can be used to develop a new
system.
• If so, the SDLC is followed to develop the system,
and the prototype is a model.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
141 of 171
PROTOTYPING
– Alternately, they may be used as the initial
prototype for an expanded system designed
to meet needs of many users.
– As a final alternative, if users and developers
decide the system is unsalvageable, the
prototype can be discarded completely.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
142 of 171
PROTOTYPING
• When to Use Prototyping
– Prototyping supports rather than replaces the SDLC.
– It is appropriate when:
• Users don’t fully understand their needs, or the needs
change rapidly
• System requirements are difficult to define
• System inputs and outputs are not known
• The task to be performed is unstructured or semi-structured
• Designers are uncertain about what technology to use
• The system is crucial and needed quickly
• The risk of developing the wrong system is high
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
143 of 171
PROTOTYPING
• The users’ reactions to the new system are important
development considerations
• Many design strategies must be tested
• The design staff has little experience developing this type of
system or application
• The system will be used infrequently so that processing
efficiency is not crucial
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
144 of 171
PROTOTYPING
• Good candidates for prototyping:
– Decision support systems
– Executive information systems
– Expert systems
– Information retrieval systems
– Systems that involve experimentation and
trial-and-error development
– Systems in which requirements evolve as the
system is used
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
145 of 171
PROTOTYPING
• Prototyping is usually inappropriate for:
– Large or complex systems that:
• Serve major organizational components; or
• Cross numerous organizational boundaries.
– Standard AIS components, such as:
• Accounts receivable
• Accounts payable
• Inventory management
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
146 of 171
PROTOTYPING
• Advantages of Prototyping:
– Better definition of user needs
• Because of intensive end-user involvement.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
147 of 171
PROTOTYPING
• Advantages of Prototyping:
– Better definition of user needs
– Higher user involvement and satisfaction
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
148 of 171
PROTOTYPING
• Advantages of Prototyping:
– Better definition of user needs
– Higher user involvement and satisfaction
– Faster development time
• It may take days or weeks to get a prototype up vs. a
year or more for a traditional system.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
149 of 171
PROTOTYPING
• Advantages of Prototyping:
– Better definition of user needs
– Higher user involvement and satisfaction
– Faster development time
– Fewer errors
• Errors are detected early because the users
experiment with each version.
• It’s also easy to identify and terminate an infeasible
AIS early.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
150 of 171
PROTOTYPING
• Advantages of Prototyping:
– Better definition of user needs
– Higher user involvement and satisfaction
– Faster development time
– Fewer errors
– More opportunity for changes
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
151 of 171
PROTOTYPING
• Advantages of Prototyping:
– Better definition of user needs
– Higher user involvement and satisfaction
– Faster development time
– Fewer errors
– More opportunity for changes
– Less costly
• Some for 10-20% of the cost of traditional systems.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
152 of 171
PROTOTYPING
• Disadvantages of Prototyping:
– Significant user time
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
153 of 171
PROTOTYPING
• Disadvantages of Prototyping:
– Significant user time
– Less efficient use of system resources
• Shortcuts in developing the system may
result in:
– Poor performance and reliability
– High maintenance and support costs
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
154 of 171
PROTOTYPING
• Disadvantages of Prototyping:
– Significant user time
– Less efficient use of system resources
– Incomplete system development
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
155 of 171
PROTOTYPING
• Disadvantages of Prototyping:
– Significant user time
– Less efficient use of system resources
– Incomplete system development
– Inadequately tested and documented
systems
• Who wants to do that stuff?
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
156 of 171
PROTOTYPING
• Disadvantages of Prototyping:
– Significant user time
– Less efficient use of system resources
– Incomplete system development
– Inadequately tested and documented systems
– Negative behavioral reactions
• If the prototype is discarded, users may be upset
about using it and losing it.
• May also be dissatisfied if all their suggestions are
not incorporated or if they have to go through too
many iterations.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
157 of 171
PROTOTYPING
• Disadvantages of Prototyping:
– Significant user time
– Less efficient use of system resources
– Incomplete system development
– Inadequately tested and documented systems
– Negative behavioral reactions
– Never-ending development
• If not managed properly, the development could get
stuck in a terminal loop.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
158 of 171
INTRODUCTION
• We’ll be discussing how to obtain a new
information system by:
– Purchasing prewritten software
– Developing software in-house
– Outsourcing
• We’ll also discuss how to hasten or improve the
development process through:
– Business process reengineering
– Prototyping
– Computer-aided software engineering (CASE)
tools
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
159 of 171
Computer-Aided Software Engineering
(CASE) Tools
• Traditionally, software developers have created
software to simplify the work of others, but not
for themselves.
• Computer-aided software (or systems)
engineering (CASE) tools are an integrated
package of computer-based tools that automate
important aspects of the software development
process.
– Used to plan, analyze, design, program, and maintain
an information system.
– Also used to enhance efforts of managers, users, and
programmers in understanding information needs.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
160 of 171
Computer-Aided Software Engineering
(CASE) Tools
• CASE tools do not replace skilled
designers, but provide developers with
effective support for all SDLC phases.
• CASE software typically includes tools for:
– Strategic planning
– Project and system management
– Database design
– Screen and report layout
– Automatic code generation
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
161 of 171
Computer-Aided Software Engineering
(CASE) Tools
• Advantages of CASE technology:
– Increased productivity
• Can generate bug-free code from system
specifications.
• Can automate repetitive tasks.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
162 of 171
Computer-Aided Software Engineering
(CASE) Tools
• Advantages of CASE technology:
– Increased productivity
– Improved program quality
• Can simplify enforcement of structured
development standards, which:
– Improves quality of development.
– Reduces threat of serious design errors.
• Can check internal accuracy of design
and detect inconsistencies.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
163 of 171
Computer-Aided Software Engineering
(CASE) Tools
• Advantages of CASE technology:
– Increased productivity
– Improved program quality
– Cost savings
• Cost savings of up to 80-90% are possible.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
164 of 171
Computer-Aided Software Engineering
(CASE) Tools
• Advantages of CASE technology:
– Increased productivity
– Improved program quality
– Cost savings
– Improved control procedures
• Encourages development early in the
design process of:
–
–
–
–
System controls
Security measures
System auditability
Error handling procedures
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
165 of 171
Computer-Aided Software Engineering
(CASE) Tools
• Advantages of CASE technology:
– Increased productivity
– Improved program quality
– Cost savings
– Improved control procedures
– Simplified documentation
 Automatically documents as the system
development progresses.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
166 of 171
Computer-Aided Software Engineering
(CASE) Tools
• Problems with CASE technology:
– Incompatibility
• Some tools don’t interact effectively with
some systems.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
167 of 171
Computer-Aided Software Engineering
(CASE) Tools
• Problems with CASE technology:
– Incompatibility
– Cost • Some packages > $360,000.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
168 of 171
Computer-Aided Software Engineering
(CASE) Tools
• Problems with CASE technology:
– Incompatibility
– Cost
– Unmet expectations
• Only 37% of CIOs believe they achieved expected
benefits.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
169 of 171
SUMMARY AND CONCLUSIONS
• You’ve learned:
– How organizations buy software, hardware,
and vendor services.
– How information systems departments
develop custom software.
– How end users develop, use and control
computer-based information systems.
– Why organizations outsource their information
systems, as well as the benefits and risks of
doing so.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
170 of 171
SUMMARY AND CONCLUSIONS
• You’ve also learned:
– What reengineering processes entail and
when they are appropriate.
– How prototypes are used to develop an AIS
and when it is advantageous to do so.
– What computer-aided software engineering is
and how it’s used in systems development.
© 2006 Prentice Hall Business Publishing
Accounting Information Systems, 10/e
Romney/Steinbart
171 of 171