2. 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
3. Systems Development Life Cycle
1. Systems Strategy
- Assessment
- Develop Strategic Plan
1. Systems Strategy
- Assessment
- Develop Strategic Plan
2. Project Initiation
- Feasibility Study
- Analysis
- Conceptual Design
- Cost/Benefit Analysis
2. Project Initiation
- Feasibility Study
- Analysis
- Conceptual Design
- Cost/Benefit Analysis
3. In-house Development
- Construct
- Deliver
3. In-house Development
- Construct
- Deliver
4. Commercial Packages
- Configure
- Test
- Roll-out
4. Commercial Packages
- Configure
- Test
- Roll-out
5. Maintenance & Support
- User help desk
- Configuration Management
- Risk Management & Security
5. Maintenance & Support
- User help desk
- Configuration Management
- Risk Management & Security
SSystemystem Interfaces, ArchitectureInterfaces, Architecture
and Uand Userser RRequirementsequirements
BBusinessusiness RRequirementsequirements
High Priority Proposals undergoHigh Priority Proposals undergo
Additional Study and DevelopmentAdditional Study and Development
FeedbackFeedback::
User requests for New SystemsUser requests for New Systems
Selected System ProposalsSelected System Proposals
go forward for Detailedgo forward for Detailed
DesignDesign
New and RevisedNew and Revised
Systems Enter intoSystems Enter into
ProductionProduction
Business Needs and
Strategy
Legacy Situation
FeedbackFeedback::
User requests for SystemUser requests for System
Improvements and SupportImprovements and Support
4. 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
5. 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
6. 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
7.
8. 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
9. 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.
11. 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.
12. 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
14. 1
2
7
3
4
6
8
9
Purchase Equipm
ent
Install and
Test Equipm
ent
Design Data Model Create Data Structures
5
Design Process
Code Programs
TestPrograms
Prepare Docum
entation
Convert Data Files
Test System
TrainPersonnel
Cut Over
to New
System
A
=
3 W
eeks
B = 4 Weeks
C
=
4 W
eeks
D
=
2 W
eeks
E = 5 Weeks
F = 5 Weeks
G
=3W
eeks
H
=
3
W
eeks
I = 3 Weeks
J =
4 W
eeks
L
=
4 W
eeks
K
=
3W
eeks
Construct Phase Deliver Phase
Project Evaluation and Review
Technique (PERT)
PERT charts show the relationship among key activities
that constitute the construct and delivery process.
15. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Project Week
Purchase Equipment
Design Data Model
Install and Test Equipment
Design Process
Code Programs
Test Programs
Create Data Structures
Prepare Documentation
Convert Data Files
Test System
Cut Over to New System
Train Personnel
CurrentPointinTime
Budgeted
Actual
Gantt Chart
represents time horizontally and activities vertically
16. 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
17. 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.
18. 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
19. Part Number Description
Quantity
on Hand Reorder Point Order Quantity
Inventory
Reduce
Review
Quantity
Reorder Replace
Attributes
Object
Operations
20. 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.
Inventory
Wheel Bearing Alternator Water Pump
Object
Class
Instance
21. 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.
22. 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
23. 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.
24. 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
25. 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
26. 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.
27. 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.
Physical User Views:
Input Views
28. 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.
30. 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
31. 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
32. 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
34. 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. 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:
Documenting
41. 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
42. 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:
Converting the Databases
43. 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:
Post-Implementation Review
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.
46. 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.
51. 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