Adv ais other dev approaches

T OPIC SEVEN

Other AIS Development
Approaches

© 2012 UMT Advanced Accounting Information Systems 1

INTRODUCTION

• We’ll also discuss how to hasten or
improve the development process through:
– Business process reengineering
– Prototyping
– Computer-aided software engineering (CASE)
tools


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.



• 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.



• 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.



business processes:
- Require those who use the output to perform the
process.



Michael Hammer has set forth several principles
business processes:
process.
- Require those who produce information to
process it.


• You centralize operations to achieve economies
of scale and eliminate redundancy.
• You decentralize operations to be more
responsive to customers and provide better
business processes:
service
- Organizetechnology, you don’t tasks. to choose.
• With around outcomes, not have
– 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.



business processes:
- 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.
- Integrate parallel activities.



business traditional system, there is a layer of worker
• In a processes:
bees and several layers of manager bees,
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.


business processes:
process.
- Require those who produce information to process it.
• 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.


• 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.



• 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.



• Challenges Faced by Reengineering Efforts:
• Tradition
• Resistance
• Change is always met with resistance.
• Requires continual reassurance, persuasion, and
support.



• Tradition
• Resistance
• Time and cost requirements
• Two or more years are required to complete BPR.



• Tradition
• Resistance
• Lack of management support
• Managers are nervous about the “big hype—few
results” syndrome.
• Without their support, the effort will fail.



• Tradition
• Resistance
• Skepticism
• BPR is sometimes viewed as just the same picture
in a different frame.



• Tradition
• Resistance
• Skepticism
• Retraining
• The necessary retraining costs time and dollars.



• Tradition
• Resistance
• Skepticism
• Retraining
• Controls
• Cannot skip the inclusion of controls to ensure
reliability and integrity.


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


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.


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.


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.

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


PROTOTYPING

prototype:


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.

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.


PROTOTYPING

prototype:


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.


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

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


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.


PROTOTYPING

prototype:


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.


PROTOTYPING

prototype:


PROTOTYPING

• The final step involves using the system
approved by the users.
• An approved prototype is typically used in
one of two ways.


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.


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.


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.


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.


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.


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.


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.


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


PROTOTYPING

• Advantages of prototyping:
– Better definition of user needs
• Because of intensive end-user involvement.


PROTOTYPING

– Higher user involvement and satisfaction


PROTOTYPING

– Faster development time
• It may take days or weeks to get a prototype up vs. a
year or more for a traditional system.


PROTOTYPING

– 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.


PROTOTYPING

– Fewer errors
– More opportunity for changes


PROTOTYPING

– Fewer errors
– More opportunity for changes
– Less costly
• Some for 10–20% of the cost of traditional systems.


PROTOTYPING

• Disadvantages of prototyping:
– Significant user time


PROTOTYPING

– Less efficient use of system resources
• Shortcuts in developing the system may
result in:
– Poor performance and reliability
– High maintenance and support costs


PROTOTYPING

– Incomplete system development


PROTOTYPING

– Inadequately tested and documented
systems • Who wants to do that stuff?


PROTOTYPING

– 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.

PROTOTYPING

– Inadequately tested and documented systems
– Negative behavioral reactions
– Never-ending development
• If not managed properly, the development could get
stuck in a terminal loop.


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.

(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

(CASE) Tools
• Advantages of CASE technology:
– Increased productivity
• Can generate bug-free code from system
specifications.
• Can automate repetitive tasks.


(CASE) Tools
– 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.


(CASE) Tools
– Cost savings
• Cost savings of up to 80–90% are possible.


(CASE) Tools
– Cost savings
– Improved control procedures
• Encourages development early in the
design process of:
– System controls
– Security measures
– System auditability
– Error handling procedures

(CASE) Tools
– Cost savings
– Improved control procedures
– Simplified documentation
Automatically documents as the system
development progresses.


(CASE) Tools
• Problems with CASE technology:
– Incompatibility
• Some tools don’t interact effectively with
some systems.


(CASE) Tools
– Incompatibility
– Cost • Some packages > $360,000.


(CASE) Tools
– Incompatibility
– Cost
– Unmet expectations
• Only 37% of CIOs believe they achieved expected
benefits.


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.


Adv ais other dev approaches

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Adv ais other dev approaches

Similar a Adv ais other dev approaches (20)

Adv ais other dev approaches