construct, deliver, and maintain systems projects
DESCRIPTION
Accounting Information Systems, 6th edition James A. HallTRANSCRIPT
Accounting Information Systems, 6th edition
James A. Hall
COPYRIGHT © 2009 South-Western, a division of Cengage Learning. Cengage Learning and South-Western
are trademarks used herein under license
Objectives for Chapter 14The sequence of events that constitutes the in-house
development phase of SDLCTools used to improve the success of systems construction
and delivery activities: CASE tools; PERT and Gantt chartsDistinction between structured and object-oriented design
approachesMulti-level DFDs in the design of business processesTypes of systems documentation and the purposes they
serveThe role of accountants in the construction and delivery of
systemsThe advantages and disadvantages of the commercial
software option
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, Architecture Interfaces, Architecture and Uand User ser RRequirementsequirements
BBusiness usiness RRequirementsequirements
High Priority Proposals undergo High Priority Proposals undergo Additional Study and DevelopmentAdditional Study and Development
FeedbackFeedback::User requests for New SystemsUser requests for New Systems
Selected System Proposals Selected System Proposals go forward for Detailed go forward for Detailed
DesignDesign
New and Revised New and Revised Systems Enter into Systems Enter into
ProductionProduction
Business Needs and Strategy
Legacy Situation
FeedbackFeedback::User requests for System User requests for System Improvements and SupportImprovements and Support
Overview of Phases 3, 4 and 5Phase 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 5Phase 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 5Phase 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
Why Up to 25% of All Systems Projects FailPoorly specified systems requirements
communication problemstime pressures
Ineffective development techniquespaper, pencils, templates, erasers instead of
software tools, such as CASE
Lack of user involvement in systems development
PrototypingA 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.
IdentifyConceptualUserSpecifications
DevelopPrototype
PresentPrototypeto Users
ObtainUserFeedback
ChangePrototypePer UserFeedback
DevelopPrototypeinto FinishedSystem
Discard Prototypeand DevelopSystem UnderTraditionalSDLC 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 ToolsDefine user requirementsCreate physical databases from
conceptual user viewsProduce 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
1
27
3
4
6
8
9
Purch
ase E
quipm
ent
Install and Test Equipment
Design Data Model Create Data Structures
5
Design Process
Code Programs Test
Prog
ram
s
Prepare
Doc
umen
tation
Convert Data Files
Test System
Train Personnel
Cut Over
to N
ew Syste
m
A = 3 Wee
ks
B = 4 Weeks
C = 4 Weeks
D = 2 Weeks
E = 5 Weeks
F = 5 Weeks G =
3 W
eeks
H = 3 W
eeks
I = 3 Weeks
J = 4 Weeks
L = 4 Week
s
K = 3 Weeks
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.
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
Cur
rent
Poi
nt in
Tim
e
Budgeted
Actual
Gantt Chartrepresents time horizontally and activities vertically
Structured Design ApproachA disciplined way of designing
systems from the top downStarts 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 ApproachIt 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 ApproachObjects: 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
Part Number DescriptionQuantity on Hand Reorder Point Order Quantity
Inventory
Reduce ReviewQuantity
Reorder Replace
Attributes
Object
Operations
Classes and InstancesAn 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
ObjectClass
Instance
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 DesignFollows 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 controlsperform system walkthroughs
Data ModelingFormalizes the data requirements of the
business process as a conceptual modelEntity-relationship diagram (ERD)
the primary tool for data modelingused to depict the entities or data objects in
the systemEach entity in an ERD is a candidate for
a conceptual user view that must be supported by the database.
NormalizationUser 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 anomaliesDepends on the extent that the data requirements of all
users have been properly specified in the data modelREA modeling facilitates normalization by identifying
entities at their most fundamental levelsThe 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-summarization-except orientation
-timely-accurate-complete-concise
Output Reporting TechniquesDifferent 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.
Input views are used to capture the relevant facts in business processes and transactions (e.g., via REA model):ResourcesEventsAgents
Input may be either hard copy input documents or electronic input.
Physical User Views: Input Views
Designing Hard Copy InputItems 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 DevicesPoint-of-sale terminalsTouch screensMouseMagnetic ink character recognition
devicesOptical character recognition
devicesVoice 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 logicallyDecompose high-level DFDs into more
detailed lower-level DFDsContext-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 modulesstrongly cohesive - small number of
tasks performed in each module
Designing System ControlsThe last step in the detailed design phaseNeed to consider:
computer processing controlsdata base controlsmanual controls over input to and output from
the systemoperational 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 WalkthroughUsually performed by the
development teamEnsure 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 SoftwareIf the organization intends to develop
software in-house, then a programming language must be selected:procedural languages or 3GLs COBOLevent-driven languages Visual Basicobject-oriented languages Java
The Modular Approach to Programming
Promotes programming efficiency modules can be both programmed and
tested independentlyPromotes 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:TestingPrograms 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.
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 manualsuser documentation - instructions on how to
use the system, tutorials, and help featuresaccountants and auditors - all of the above
as well as document flowcharts
Deliver the System:Documenting
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
conversionreconciliation – reconcile the new converted
database against the originalbackup - 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 systemriskiest approach
Phased - modules are implemented in a piecemeal fashionreduces risk of a devastating failure
Parallel operation - the old system and new system are run simultaneously for awhilesafest, yet costliest, approach
Deliver the System:Converting the Databases
Objective: measure the success of the new system.do after initial problems have been addressed
Assess:system design adequacyaccuracy 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
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 requirementsspecifying documentation standards for
auditing purposesverifying control adequacy in accordance
with SAS 78
The Purchase of Commercial Systems Packages
Four factors have stimulated the growth of commercial software:relatively low costprevalence of industry-specific vendorsgrowing demand by small businessestrend 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 timedecreased costreduced probability of program errors
Disadvantages:dependent on the vendor for maintenanceless flexibility in systemgreater 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.
Maintenance and SupportApproximately 80% of the life and costs of
SDLCCan be outsourced or done in-house resourcesEnd user support is a critical aspect of
maintenance that can be facilitated by:knowledge management - method for gathering,
organizing, refining, and disseminating user inputgroup memory - method for collecting user input
for maintenance and support
The Iceberg Effect