Pp 14-new

Hall, Accounting Information Systems, 8e
©2013 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Accounting Information Systems, 8e
James A. Hall
Chapter 14
Construct, Deliver, and Maintain
Systems Projects

Objectives for Chapter 14
 Be able to identify the sequence of events that constitutes the in-
house development phase of SDLC.
 Be familiar with tools used to improve the success of systems
construction and delivery activities including prototyping, CASE
tools, and the use of PERT and Gantt charts.
 Understand the distinction between structured and object-oriented
design approaches.
 Understand the use of multi-level DFDs in the design of business
processes.
 Be familiar with the different types of systems documentation and
the purposes they serve.
 Recognize the role of accountants in the construction and delivery of
systems.
 Understand the advantages and disadvantages of the commercial
software option and be able to discuss the decision-making process
used to select commercial software.
2

System Development Life Cycle
3
Figure 14-1

Overview of Phases 3, 4 and 5
 Phase 3. In-House Development
 appropriate when organizations have unique
information needs
 steps include:
• analyzing user needs
• designing processes and databases
• creating user views
• programming the applications
• testing and implementing the completed system
4

 Phase 4. Commercial Packages
 When acceptable, most organizations will seek
a pre-coded commercial software package.
 advantages:
• lower initial cost
• shorter implementation time
• better controls
• rigorous testing by the vendor
 risks:
• must adequately meet end users’ needs
• compatible with existing systems
5

 Phase 5. Maintenance and Support
 acquiring and implementing the latest software
versions of commercial packages
 making in-house modifications to existing systems
to accommodate changing user needs
 may be relatively trivial, such as modifying an
application to produce a new report, or more
extensive, such as programming new functionality
into a system
6

James A. Hall
Phase 3
Systems Strategy

Why Up to 25% of All Systems
Projects Fail
 Poorly specified systems requirements
 communication problems
 time pressures
 Ineffective development techniques
 paper, pencils, templates, erasers instead of
software tools, such as CASE
 Lack of user involvement in systems
development
8

Prototyping
 A technique for providing a preliminary
working version of the system
 Built quickly and relatively inexpensively with
the intention it will be modified
 End users work with the prototype and make
suggestions for changes.
 A better understanding of the true
requirements of the system is achieved.
9

Prototyping Techniques
10
Figure 14-2

Computer-Aided Software
Engineering (CASE)
 CASE technology involves the use of
computer systems to build computer
systems.
 CASE tools are commercial software
products consisting of highly integrated
applications that support a wide range
of SDLC activities.
11

Uses of CASE Tools
 Define user requirements
 Create physical databases from
conceptual user views
 Produce system design specifications
 Automatically generate program code
 Facilitate the maintenance of programs
created by both CASE and non-CASE
techniques
12

CASE Spectrum of Support Tools
for the SDLC
13

1
2
3
4
6
8
9
Design Data Model Create Data Structures
5
Convert Data Files
B = 4 Weeks E = 5 Weeks I = 3 Weeks
Construct Phase Deliver Phase
PERT Chart for In-House
Development Project
PERT charts show the relationship among key activities
that constitute the construct and delivery process.
14
Figure 14-4

15
Gantt Chart
Figure 14-5

Structured Design Approach
 A disciplined way of designing systems
from the top down
 Starts with the “big picture” of the
proposed system and gradually
decomposes it into greater detail so
that it may be fully understood
 Utilizes data flow diagrams (DFDs) and
structure diagrams
16

Object-Oriented Design Approach
 It builds information systems from
reusable standard components or
objects.
 Once created, standard modules can
be used in other systems with similar
needs.
 A library of modules can be created for
future use.
17

Elements of the Object-Oriented
Approach
 Objects: equivalent to nouns
 vendors, customers, inventory, etc.
 Attributes: equivalent to adjectives
 part number, quantity on hand, etc.
 Operations: equivalent to verbs
 review quantity on hand, reorder item
18

Characteristics of an Inventory
Object
19
Figure 14-8

Classes and Instances
 An object class is a logical grouping of
individual objects that share the same
attributes and operations.
 An object instance is a single occurrence of
an object within a class.
20

Inheritance
 Inheritance means that each object
instance inherits the attributes and
operations of the class to which it
belongs.
 Object classes may also inherit from
other object classes.
21

Systems Design
 Follows a logical sequence of events:
 model the business process and design
conceptual views
 design normalized database tables
 design physical user views (output and input
views)
 develop process modules
 specify system controls
 perform system walkthroughs
22

Data Modeling
 Formalizes the data requirements of the
business process as a conceptual model
 Entity-relationship diagram (ERD)
 the primary tool for data modeling
 used to depict the entities or data objects in
the system
 Each entity in an ERD is a candidate for
a conceptual user view that must be
supported by the database.
23

Normalization
 User views in the data model must be
supported by normalized database tables.
 Normalization of database tables:
 A process of organizing tables so that entities are
represented unambiguously
 Eliminates data redundancies and associated
anomalies
 Depends on the extent to which the data
requirements of all users have been properly
specified in the data model
 REA modeling facilitates normalization by identifying
entities at their most fundamental levels
 The resulting databases will support multiple user
views
 Described in more detail in chapter 9.
24

Physical User Views:
Output Views
 Output is the information produced by the
system to support user tasks and decisions.
 Output attributes:
-relevance
-summarization
-exception orientation
-timeliness
-accuracy
-completeness
-conciseness
25

Output Reporting Techniques
 Different users prefer different styles of
output…
 tables, matrices, charts, and graphs
 …and modes of output.
 hard copy vs. display screen.
 Systems designers must identify these
styles and provide output in the desired
style.
26

Physical User Views:
Input Views
 Input views are used to capture the relevant
facts in business processes and transactions
(e.g., via REA model):
 Resources
 Events
 Agents
 Input may be either hard copy input
documents or electronic input.
27

Designing Hard Copy Input
 Items to Consider:
 How will the document be handled?
 How long will the form be stored and in
what type of environment?
 How many copies are required?
 What size form is necessary?
• Non-standard form can cause printing and
storage problems.
28

Designing Electronic Input
Input may be from either hardcopy or electronic
Figure 14-14

Data Entry Devices
 Point-of-sale terminals
 Touch screens
 Mouse
 Magnetic ink character recognition
devices
 Optical character recognition devices
 Voice and touch-tone recognition
devices
30

Designing Process Modules
 Begins with the DFDs produced in the
general design phase
 First, decompose the existing DFDs to
a degree of detail that will serve as the
basis for creating structure diagrams
 Structure diagrams provide the
blueprints for writing the actual program
modules
31

Data Flow Diagrams (DFDs)
 Used to represent multiple levels of
detail.
 Can represent system physically or logically
 Context-level DFDs represent an
overview of the business activities and
the primary transactions processed by
the system.
 Do not include detailed definitions of data
files and specific procedures.
 Decompose high-level DFDs into more
detailed lower-level DFDs.
32

DFD for Purchases and Cash
Disbursements System
33
Figure 14-15

Lower Level DFD for AP Process I.4
34
Figure 14-16

The Modular Approach
 Each module performs a single task.
 Correctly designed modules possess two
attributes:
 loosely coupled - low amounts of exchange
of data between modules
 strongly cohesive - small number of tasks
performed in each module
35

Designing System Controls
 The last step in the detailed design phase
 Need to consider:
 computer processing controls
 data base controls
 manual controls over input to and output from the
system
 operational environment controls
 Allows the design team to review, modify, and
evaluate controls with a system-wide
perspective that did not exist when each
module was being designed independently
36

Systems Walkthrough
 Usually performed by the development
team
 Ensure that design is free from conceptual
errors that could become programmed into
the final system
 Some firms use a quality assurance
(QA) group to perform this task.
 An independent group of programmers,
analysts, users, and internal auditors
37

Program Application Software
 If the organization intends to develop
software in-house, then a programming
language must be selected:
 procedural languages or 3GLs
COBOL
 event-driven languages
Visual Basic
 object-oriented languages
Java
38

The Modular Approach to
Programming
 Promotes programming efficiency
 modules can be both programmed and
tested independently
 Promotes maintenance efficiency
 small modules are easier to analyze and
change
 Promotes greater control
 modules are less likely to contain material
errors of fraudulent logic
39

Deliver the System: Testing
 Programs must be thoroughly tested
before being implemented.
 All logic procedures should be tested.
 Test individual modules with test data
containing both “good” and “bad” data.
 After testing individual modules, the entire
system should tested as a whole.
40

Deliver the System: Documenting
 Describes how the system works
 Documentation should be provided for:
 designers and programmers - comment lines
in programs, system flowcharts, and program
flowcharts
 operator documentation - run manuals
 user documentation - instructions on how to
use the system, tutorials, and help features
 accountants and auditors - all of the above as
well as document flowcharts
41

Deliver the System:
Converting the Databases
 The transfer of data from its current form
to the format or medium required by the
new system
 Control risks with the following
procedures:
 validation – inspect old database before
conversion
 reconciliation – reconcile the new converted
database against the original
 backup - keep copies of the original files against
discrepancies in the converted data
42

Deliver the System:
Converting the Databases
Three data conversion cutover approaches:
 Cold turkey - switch to the new system all at once
and simultaneously terminate the old system.
 riskiest approach
 Phased - modules are implemented in a piecemeal
fashion.
 reduces risk of a devastating failure
 Parallel operation - the old system and new system
are run simultaneously for a while.
 safest, yet costliest, approach
43

Deliver the System:
Post-Implementation Review
 Objective: measure the success of the new
system.
 do after initial problems have been addressed
 Assess:
 system design adequacy
 accuracy of time, cost, and benefit estimates
 Provides feedback to improve future systems
development projects, including changes to
the current system
44

Deliver the System:
The Role of Accountants
 Most system failures are due to poor design
and improper implementation.
 Accountants should provide their expertise to
help avoid inadequate systems by:
 providing technical expertise for financial
reporting requirements
 specifying documentation standards for auditing
purposes
 verifying control adequacy in accordance with
SAS 78
45

James A. Hall
Phase 4
Commercial Packages

The Purchase of Commercial
Systems Packages
 Four factors have stimulated the growth
of commercial software:
 relatively low cost
 prevalence of industry-specific vendors
 growing demand by small businesses
 trend toward downsizing and distributed data
processing
47

Trends in Commercial Packages
 Turnkey systems - completely finished
and tested systems ready for
implementation
 Backbone systems - provide a basic
system structure on which to build.
 Vendor-supported systems - customized
and maintained by a vendor for a customer
 ERP systems - difficult to classify since
they have characteristic of all of the above.
 See chapter 11 for more details on ERP systems.
48

Pros and Cons of Commercial
Packages
 Advantages:
 decreased implementation time
 decreased cost
 reduced probability of program errors
 Disadvantages:
 dependent on the vendor for maintenance
 less flexibility in system
 greater difficulty in modifying the system as needs
change over time
49

Four Steps in Choosing a
Commercial Package
1. Analyze needs and develop detailed
specifications of the system requirements.
2. Send out the request for proposals to all
prospective vendors to serve as a
comparative basis for initial screening.
3. Gather the facts about each vendor’s
system using multiple sources and
techniques.
4. Analyze the findings and make a final
selection.
50

James A. Hall
Phase 5
Maintenance and Support

Maintenance and Support
 Approximately 80% of the life and costs of
SDLC
 Can be outsourced or done in-house
resources
 End user support is a critical aspect of
maintenance that can be facilitated by:
 knowledge management - method for gathering,
organizing, refining, and disseminating user input
 group memory - method for collecting user input
for maintenance and support
52

The Iceberg Effect
53
Figure 14-29

Pp 14-new

More Related Content

What's hot (20)

Similar to Pp 14-new (20)

More from Sri Apriyanti Husain (20)

Recently uploaded (20)

Pp 14-new