Chapter 14
Construct, Deliver, and
Maintain Systems Projects
Objectives for Chapter 14
• The sequence of events that constitute the in-house
development phase of the SDLC
• The tools used to improve the success of system construction
and delivery activities (CASE tools; PERT and Gantt charts)
• The distinction between the structured and object-oriented
design approaches
• Multi-level DFDs in the design of business processes
• The different types of system documentation and the
purposes they serve
• The role of accountants in the construct and delivery of
systems
• The advantages and disadvantages of the commercial
software option, the decision-making process used to select
commercial software
Systems Development Life Cycle
Business Needs and
Strategy
Legacy Situation
Business Requirements
1. Systems Strategy
- Assessment
- Develop Strategic Plan
System Interfaces, Architecture
and User Requirements
Feedback:
User requests for New Systems
High Priority Proposals undergo
Additional Study and Development
2. Project Initiation
- Feasibility Study
- Analysis
- Conceptual Design
- Cost/Benefit Analysis
Selected System Proposals
go forward for Detailed
Design
3. In-house Development
Feedback:
User requests for System
Improvements and Support
4. Commercial Packages
- Construct
- Deliver
- Configure
- 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 include:
•
•
•
•
lower initial cost
shorter implementation time
better controls
rigorous testing by the vendor
– risk
• must ensure that the user gets a package that
adequately meets his or her needs and is
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
In-House
Development
Up to 25% of all systems
projects fail! Why?
• Poorly specified systems
requirements
– communication problems
– time pressures
systems
• Ineffective development
developer
techniques
– paper, pencils, templates, erasers
instead of software tools, such as CASE
• Lack of user involvement in systems
development
end
user
Prototyping
• Prototyping is a technique for providing
users a preliminary working version of the
system.
• It is built quickly and relatively
inexpensively with the intention it will be
modified.
• As the 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
Conceptual
User
Specifications
Develop
Prototype
Present
Prototype
to Users
Obtain
User
Feedback
Change
Prototype
Per User
Feedback
Discard Prototype
and Develop
System Under
Traditional
SDLC Procedures
Develop
Prototype
into Finished
System
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)
Deliver Phase
Construct Phase
2
B = 4 Weeks
Design Data Model
1
E = 5 Weeks
Create Data Structures
3
I = 3 Weeks
Convert Data Files
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
Current Point in Time
Convert Data Files
Test System
Prepare Documentation
Train Personnel
Cut Over to New System
Budgeted
Actual
1
2
3
4
5
6
7
8
9
10 11 12
Project Week
13 14
15
16
17
18
19
20
21
The Structured Design
Approach…
• is 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 DFD 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 ObjectOriented 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
Part Number
Description
Quantity
on Hand
Reorder Point
Order Quantity
Inventory
Object
Operations
Reduce
Review
Quantity
Reorder
Replace
Classes and Instances
• An object class is a logical grouping of
individual objects that share the same
attributes and operations.
• An instance is a single occurrence of an
object within a class.
Inventory
Object
Class
Instance
Wheel Bearing
Alternator
Water Pump
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
• This stage follows a logical sequence of
events:
– data model the business process and design
conceptual views
– design the normalized database tables
– design the physical user views (output and
input views)
– develop the process modules
– specify the system controls
– perform a system walkthrough
Data Modeling
• Data Modeling is the task of formalizing the
data requirements of the business process
as a conceptual model.
• The primary tool is the ER diagram which is
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.
Physical User Views:
Output Views
• Output is the information produced by the
system to support user tasks and decisions.
• Output attributes:
– relevant
– summarization
– except orientation
– timely
– accurate
– 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
• Data input views are used to capture the
relevant facts about the resources,
events, and agents involved in business
process transactions.
• Input may be either
hard copy input documents
or electronic input.
Designing Hard Copy Input
• Items to Consider:
– How will the document be handled? What
quality paper?
– How long will the form be stored and in what
type of environment?
– How many copies are required?
– What size form is necessary? Nonstandard 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 the Process
Component
• This phase begins with the DFDs
produced in the general design phase.
• The first task is to decompose the
existing DFDs to a degree of detail that
will serve as the basis for creating
structure diagrams.
• The structure diagrams will provide the
blueprints for writing the actual program
modules.
Data Flow Diagrams (DFDs)
• DFDs are used to represent multiple
levels of detail.
• Context-level DFDs are used to present
an overview model of the business
activities and the primary transactions
processed by the system.
• It does not include a detailed definition 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)
Design 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
• This step 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.
System Design Walkthrough
• This step is performed by the development
team to ensure the design is free from
conceptual errors that could become
programmed into the final system.
• Some firms may use a quality assurance
group to perform the task. This is 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, such as:
– procedural languages or 3GLs
(COBOL)
– event-driven languages
(Visual Basic)
– object-oriented languages
(Java)
The Modular Approach to
Programming
• Promotes programming efficiency
since modules can be both programmed
and tested independently
• Promotes maintenance efficiency
since small modules are easier to
analyze and change
• Promotes greater control since they
are less likely to contain material errors
of fraudulent logic
Deliver the System:
Testing
• Programs must be thoroughly tested
before they are implemented.
• Individual modules should be tested with
test data containing both “good” and “bad”
data. All logic procedures should be
tested.
• After the individual modules have been
tested, the entire system should tested as
a whole.
Deliver the System:
Documenting
• Documentation describes how the system
works and should be made 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
• This is the transfer of data from its current form to the
format or medium required by the new system.
• Data conversion is risky and must be carefully
controlled by the following precautions:
– validation - old database must be inspected before
conversion
– reconciliation - after the conversion, the new
database must be reconciled against the original
– backup - copies of the original files must be kept
as backup against discrepancies in the converted
data
Deliver the System:
Converting the Databases
Three approaches:
• Cold turkey cutover - the firm switches to the
new system on a particular day and
simultaneously terminates the old system.
– This is the riskiest approach.
• Phased cutover - modules are implemented in a
piecemeal fashion.
– The risk of a devastating failure can be reduced.
• Parallel operation cutover - the old system and
new system are run simultaneously.
– This is the safest, yet costliest, approach.
Deliver the System:
Post-Implementation Review
• The objective is to measure the success
of the system and of the process after
the dust has settled. Want to assess:
– system design adequacy
– accuracy of time, cost, and benefit
estimates
• This information can provide feedback
to improve future systems development
projects.
Deliver the System:
The Role of Accountants
• Most system failures are due to poor
designs 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 are completely finished
and tested systems that are ready for
implementation.
• Backbone systems provide a basic system
structure on which to build.
• Vendor-supported systems are customdeveloped and maintained by a vendor for a
customer.
• ERP systems are difficult to classify since
they have characteristic of all of the above.
Pros and Cons of Commercial
Packages
• Advantages:
– decreased implementation time
– decreased cost
– reduced probability of program errors
• Disadvantages:
– reduced independence - the customer is
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 the
SDLC
• Can be outsourced or done with in-house
resources
• User support is a critical aspect of
maintenance. 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