Contenu connexe
Similaire à Adv ais other dev approaches
Similaire à Adv ais other dev approaches (20)
Adv ais other dev approaches
- 1. T OPIC SEVEN
Other AIS Development
Approaches
© 2012 UMT Advanced Accounting Information Systems 1
- 2. INTRODUCTION
• We’ll also discuss how to hasten or
improve the development process through:
– Business process reengineering
– Prototyping
– Computer-aided software engineering (CASE)
tools
© 2012 UMT Advanced Accounting Information Systems 2
- 3. 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.
© 2012 UMT Advanced Accounting Information Systems 3
- 4. 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.
© 2012 UMT Advanced Accounting Information Systems 4
- 5. 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.
© 2012 UMT Advanced Accounting Information Systems 5
- 6. 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.
© 2012 UMT Advanced Accounting Information Systems 6
- 7. 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.
© 2012 UMT Advanced Accounting Information Systems 7
- 8. 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
- Organizetechnology, you don’t tasks. to choose.
• With around outcomes, not have
- Require those who use the output to perform the
– Corporate-wide databases centralize data.
process.
– Telecommunications technology disburses it to the
organization.
- Require those who produce information to process it.
- Centralize AND disperse data.
© 2012 UMT Advanced Accounting Information Systems 8
- 9. BUSINESS PROCESS REENGINEERING
• Michael Hammer has set forth several principles
that help organizations successfully reengineer
business processes:
- Organize around outcomes, not tasks.
- Require those developing a new product, include thethe
Example: In
who use the output to perform on
process.
development team at least one person from each involved
- Require those so the right hand will know what the left hand
department, who produce information to process it.
is doing and the process will be smoothly integrated.
- Centralize AND disperse data.
- Integrate parallel activities.
© 2012 UMT Advanced Accounting Information Systems 9
- 10. BUSINESS PROCESS REENGINEERING
• Michael Hammer has set forth several principles
that help organizations successfully reengineer
business traditional system, there is a layer of worker
• In a processes:
bees and several layers of manager bees,
- Organize around outcomes, not tasks.
auditor bees, and controller bees.
- Requirereengineered system, the people who do the
• In a those who use the output to perform the
process. have decision-making responsibility.
work
- Require those who produceenables their decision
– Information technology information to process it.
- accuracy.
Centralize AND disperse data.
- Integrate parallel activities. process itself.
– Controls are built into the
- Empower workers, use built-in controls, and
flatten the organization chart.
© 2012 UMT Advanced Accounting Information Systems 10
- 11. 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 AND disperse data.
• Instead of having each functional area running its own AIS
- Integrateentering the same data, use source data automation,
and parallel activities.
- Empoweretc. to capture data electronically at theflatten and
EDI, workers, use built-in controls, and source
the organization chart. it needs to be used.
disburse it to where
- Capture data once—at its source.
© 2012 UMT Advanced Accounting Information Systems 11
- 12. 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.
© 2012 UMT Advanced Accounting Information Systems 12
- 13. 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.
© 2012 UMT Advanced Accounting Information Systems 13
- 14. 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.
© 2012 UMT Advanced Accounting Information Systems 14
- 15. 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.
© 2012 UMT Advanced Accounting Information Systems 15
- 16. 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.
© 2012 UMT Advanced Accounting Information Systems 16
- 17. 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.
© 2012 UMT Advanced Accounting Information Systems 17
- 18. 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.
© 2012 UMT Advanced Accounting Information Systems 18
- 19. 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.
© 2012 UMT Advanced Accounting Information Systems 19
- 20. 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
© 2012 UMT Advanced Accounting Information Systems 20
- 21. 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.
© 2012 UMT Advanced Accounting Information Systems 21
- 22. 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.
© 2012 UMT Advanced Accounting Information Systems 22
- 23. 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.
© 2012 UMT Advanced Accounting Information Systems 23
- 24. 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
© 2012 UMT Advanced Accounting Information Systems 24
- 25. 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
© 2012 UMT Advanced Accounting Information Systems 25
- 26. 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.
© 2012 UMT Advanced Accounting Information Systems 26
- 27. 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.
© 2012 UMT Advanced Accounting Information Systems 27
- 28. 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
© 2012 UMT Advanced Accounting Information Systems 28
- 29. 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.
© 2012 UMT Advanced Accounting Information Systems 29
- 30. PROTOTYPING
• Because of time constraints, some
aspects are sacrificed. For example, at
this point, you ignore:
– Non-essential functions
– System controls
– Exception handling
– Validation of input data
– Processing speed
– Efficiency considerations
© 2012 UMT Advanced Accounting Information Systems 30
- 31. 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
© 2012 UMT Advanced Accounting Information Systems 31
- 32. 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.
© 2012 UMT Advanced Accounting Information Systems 32
- 33. 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
© 2012 UMT Advanced Accounting Information Systems 33
- 34. 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 to 6 iterations.
© 2012 UMT Advanced Accounting Information Systems 34
- 35. 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
© 2012 UMT Advanced Accounting Information Systems 35
- 36. PROTOTYPING
• The final step involves using the system
approved by the users.
• An approved prototype is typically used in
one of two ways.
© 2012 UMT Advanced Accounting Information Systems 36
- 37. 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.
© 2012 UMT Advanced Accounting Information Systems 37
- 38. 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.
© 2012 UMT Advanced Accounting Information Systems 38
- 39. 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.
© 2012 UMT Advanced Accounting Information Systems 39
- 40. 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.
© 2012 UMT Advanced Accounting Information Systems 40
- 41. 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.
© 2012 UMT Advanced Accounting Information Systems 41
- 42. 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.
© 2012 UMT Advanced Accounting Information Systems 42
- 43. 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.
© 2012 UMT Advanced Accounting Information Systems 43
- 44. 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
© 2012 UMT Advanced Accounting Information Systems 44
- 45. PROTOTYPING
• Advantages of prototyping:
– Better definition of user needs
• Because of intensive end-user involvement.
© 2012 UMT Advanced Accounting Information Systems 45
- 46. PROTOTYPING
• Advantages of prototyping:
– Better definition of user needs
– Higher user involvement and satisfaction
© 2012 UMT Advanced Accounting Information Systems 46
- 47. 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.
© 2012 UMT Advanced Accounting Information Systems 47
- 48. 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.
© 2012 UMT Advanced Accounting Information Systems 48
- 49. PROTOTYPING
• Advantages of prototyping:
– Better definition of user needs
– Higher user involvement and satisfaction
– Faster development time
– Fewer errors
– More opportunity for changes
© 2012 UMT Advanced Accounting Information Systems 49
- 50. 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.
© 2012 UMT Advanced Accounting Information Systems 50
- 51. PROTOTYPING
• Disadvantages of prototyping:
– Significant user time
© 2012 UMT Advanced Accounting Information Systems 51
- 52. 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
© 2012 UMT Advanced Accounting Information Systems 52
- 53. PROTOTYPING
• Disadvantages of prototyping:
– Significant user time
– Less efficient use of system resources
– Incomplete system development
© 2012 UMT Advanced Accounting Information Systems 53
- 54. 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?
© 2012 UMT Advanced Accounting Information Systems 54
- 55. 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.
© 2012 UMT Advanced Accounting Information Systems 55
- 56. 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.
© 2012 UMT Advanced Accounting Information Systems 56
- 57. 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.
© 2012 UMT Advanced Accounting Information Systems 57
- 58. 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
© 2012 UMT Advanced Accounting Information Systems 58
- 59. Computer-Aided Software Engineering
(CASE) Tools
• Advantages of CASE technology:
– Increased productivity
• Can generate bug-free code from system
specifications.
• Can automate repetitive tasks.
© 2012 UMT Advanced Accounting Information Systems 59
- 60. 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.
© 2012 UMT Advanced Accounting Information Systems 60
- 61. 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.
© 2012 UMT Advanced Accounting Information Systems 61
- 62. 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
© 2012 UMT Advanced Accounting Information Systems 62
- 63. 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.
© 2012 UMT Advanced Accounting Information Systems 63
- 64. Computer-Aided Software Engineering
(CASE) Tools
• Problems with CASE technology:
– Incompatibility
• Some tools don’t interact effectively with
some systems.
© 2012 UMT Advanced Accounting Information Systems 64
- 65. Computer-Aided Software Engineering
(CASE) Tools
• Problems with CASE technology:
– Incompatibility
– Cost • Some packages > $360,000.
© 2012 UMT Advanced Accounting Information Systems 65
- 66. Computer-Aided Software Engineering
(CASE) Tools
• Problems with CASE technology:
– Incompatibility
– Cost
– Unmet expectations
• Only 37% of CIOs believe they achieved expected
benefits.
© 2012 UMT Advanced Accounting Information Systems 66
- 67. SUMMARY AND CONCLUSIONS
• You’ve 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.
© 2012 UMT Advanced Accounting Information Systems 67