Chapter 14

Construct, Deliver, and Maintain

Systems Projects

Accounting Information Systems, 5th edition

James A. Hall

COPYRIGHT © 2007 Thomson South-Western, a part of The Thomson Corporation. Thomson, the Star logo,
and South-Western are trademarks used herein under license
 Objectives for Chapter 14
• The sequence of events that constitutes the in-house
development phase of SDLC
• Tools used to improve the success of systems construction
and delivery activities: CASE tools; PERT and Gantt charts
• Distinction between structured and object-oriented design
approaches
• Multi-level DFDs in the design of business processes
• Types of systems documentation and the purposes they serve
• The role of accountants in the construction and delivery of
systems
• The advantages and disadvantages of the commercial
software option
 Systems Development Life Cycle

Business Needs and

Strategy

Legacy Situation
Business Requirements

1. Systems Strategy
-- Assessment
Assessment Feedback:
Feedback:
-- Develop
Develop Strategic
Strategic Plan
Plan User requests for New Systems
System Interfaces, Architecture
and User Requirements
High Priority Proposals undergo
Additional Study and Development

2. Project Initiation
- Feasibility
Feasibility Study
Study
-- Analysis
Analysis
- Conceptual
Conceptual Design
Design
- Cost/Benefit
Cost/Benefit Analysis
Analysis Feedback:
Feedback:
User requests for System
Selected System Proposals Improvements and Support
go forward for Detailed
Design

3. In-house Development 4. Commercial Packages

-- Construct
Construct -- Configure
Configure
-- Deliver
Deliver -- Test
Test
-- Roll-out
Roll-out

New and Revised

Systems Enter into
Production

5. Maintenance & Support

-- User
User help
help desk
desk
-- Configuration
Configuration Management
Management
-- Risk
Risk Management
Management && Security
Security
 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
 Overview of Phases 3, 4 and 5
• 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
 Overview of Phases 3, 4 and 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
 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
 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.
 Prototyping Techniques

Identify Present Obtain Change Develop

Conceptual Develop Prototype User Prototype Prototype
User Prototype to Users Feedback Per User into Finished
Specifications Feedback System

Discard Prototype
and Develop
System Under
Traditional
SDLC Procedures
 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.
 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
CASE Spectrum of Support
Tools for the SDLC
 Project Evaluation and Review
Technique (PERT)
Construct Phase Deliver Phase

2
In D 7
sta =
ll 2
t an W n

K rain
en d T eek io
tat

= Pe
T
ks p m es s

3 W rs
ee q u i tE en
ks um
3W E

ee onn
qu ee oc
= ase

ks el
ip W D
A rch m 3 e
en = par
Pu t H re
B = 4 Weeks E = 5 Weeks P I = 3 Weeks
Design Data Model Create Data Structures Convert Data Files
1 3 6 9
De C J
si g = 4 m
nP W Te = 4 W y ste
og ks
s

ro eek st S
ks ew
ram
Pr ee

ce s Sy eek e
e N
st W

ss ste s
m 4 W r to
Te = 3

F = 5 Weeks =
L Ove
G

4 Code Programs t
5 Cu
8

PERT charts show the relationship among key activities

that constitute the construct and delivery process.
 Gantt Chart
represents time horizontally and activities vertically
Purchase Equipment

Design Data Model

Design Process

Install and Test Equipment

Code Programs

Test Programs

Create Data Structures

Convert Data Files

Current Point in Time

Test System

Prepare Documentation

Train Personnel

Cut Over to New System

Budgeted
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Actual
Project Week
 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
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.
 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
 Characteristics of an Inventory
Object
Attributes
Quantity
Part Number Description on Hand Reorder Point Order Quantity

Object Inventory

Operations
Review
Reduce Reorder Replace
Quantity
 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.

Object Inventory
Class

Instance Water Pump

Wheel Bearing Alternator
 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.
 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
 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 ER diagram is a candidate
for a conceptual user view that must be
supported by the database.
 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 that 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
 Physical User Views:
Output Views
• Output is the information produced by the
system to support user tasks and decisions.
• Output attributes:
-relevant -timely
-accurate
-summarization
-complete
-except orientation -concise
 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.
 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.
 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.
Designing Electronic Input
Input may be from either hardcopy or electronic
 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
 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
 Data Flow Diagrams (DFDs)
• Used to represent multiple levels of detail
– Can represent system physically or logically
• Decompose high-level DFDs into more
detailed lower-level DFDs
• 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
Lower-Level DFD for an AP Process
 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
 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
 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
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
 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
 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.
 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
 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
 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 awhile
– safest, yet costliest, approach
 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
 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
 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
 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
 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
 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.
 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
The Iceberg Effect