Construct, Deliver, and Maintain

Systems Projects
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 Feedback:
- Develop Strategic Plan User requests for New Systems
System Interfaces, Architecture
and User Requirements
High Priority Proposals undergo
Additional Study and Development

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

3. In-house Development 4. Commercial Packages

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

New and Revised

Systems Enter into
Production

5. Maintenance & Support

- User help desk
- Configuration Management
- Risk Management & 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

B = 4 Weeks E = 5 Weeks I = 3 Weeks

Design Data Model Create Data Structures Convert Data Files
1 3 6 9

4
5
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 ERD 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
-summarization -accurate
-except orientation -complete
-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