Chapter 5 Systems Development and

Program Change Activities

Overview:
Identify stages of SDLC (systems development life cycle)
Common problems that lead to failure in the systems development
Understand strategic system planning
Accountants role in SDLC
Structured and object-oriented approaches to system design
Cost-benefit analysis of proposed information systems
Pros/cons of commercial software option and discuss decision-making process
System walkthrough
System documentation and their purpose
Participants in systems development
Systems professionals those who build the program
End users whom the system is built for
Stakeholders within/outside of organization who have an interest but are not end
users
Accountants/auditors addresses controls, accounting/auditing issues
Why are accountants/auditors involved?
Significant financial information and transactions
Nature of the products that emerge from the SDLC, quality of accounting
information
Info systems acquisitions
In-house development require systems that are highly unique
Commercial systems low costs, industry-specific vendors, businesses are too small
to in-house, downsizing of organizations
o Turnkey systems: finished and tested systems that are ready for
implementation
General accounting systems (i.e. Simply Accounting) purchase
modules that meet their specific needs (i.e. AR module)
Special-purpose systems target selected segments of the economy
(i.e. medicine) that have unique accounting procedures and rules
Office automation system (Microsoft office)
o Backbone systems: provide basic system with all primary processing
modules programmed
o Vendor-supported systems: hybrids of custom and commercial systems. The
system themselves are custom but the development service is commercially

available client is dependent on the vendor for custom programming and

maintenance
Pros of custom
o Short implementation time, low cost, reliable
Cons of custom
o Independence, the need for custom, and maintenance dependence

SDLC (Systems Development Life Cycle)

8 steps:
o Plan
Linking projects to objectives of the company
Strategic systems planning involves the allocation of systems
resources at the macro level (i.e. resource budgeting)
Why?
A plan is better than no plan
Reduces crisis component in systems development
Provides authorization control for SDLC
Cost management
Project planning is to allocate resources to individual applications
within the framework of the strategic plan
Project proposal provides basis for deciding whether to
proceed with the project first and connects plan to objectives
Project schedule budgets times and costs for all stages
Auditors role
Examine the systems planning phase
o Analyze
First survey the current system, then what the users needs are
Survey
o Determine what can be salvaged
o Cons: stuck thinking too much about current system,
limits creativity
o Pros: determine what should be kept, helps
understands current/new system, determining the root
problem
Gather information
o Data sources, users, data stores, processes, data flows,
controls, transaction volumes, error rates, resource
costs, bottleneck/redundant operations
How to gather information
o Observe, task participation, personal interviews, and
reviewing key documents (i.e. org charts, job
descriptions, budgets, forecasts)
Auditors role
o Auditors need to express their needs (i.e. logs, audit
trails)

o Design concept
Purpose is to provide several alternatives, to avoid posing
preconceived constraints on the new system
Structured approach
o Consists of thinking of the big picture first, then
determining all the details
Object-oriented design (OOD)
o Build info systems from reusable components (i.e. car
parts)
Auditors role
o Ensuring that the system is auditable
o Select
Two steps: feasibility and cost-benefit
5 feasibility tests
Technical, economic, legal, operational (compatibility with
existing), schedule
Identify costs (fixed/variable), benefits (tangible/intangible), and
compare
Auditors role:
Ensure costs are calculated properly, fair assumptions, realistic
useful lives, intangibles are fairly valued
o Design details
To ensure that system requirements are satisfied and in accordance
with design
Perform walkthroughs
Ensure design is free of errors
Have a QA group
o Program/test
Select appropriate programming language
Procedural: specify order in which program logic is executed
Event-driven: when specific events order (i.e. click)
Object-oriented
Using a modular approach breaking up the tasks into smaller tasks
Programming efficiency, maintenance efficiency, control
Test the application software
Create hypothetical situations and have predetermined results
to compare
Always save situations for future testing
Test offline as well
o Implement
Test the entire system
Outputs should reconcile to predetermined results
Documenting the system
o Designer & programmers to help debug error and
perform maintenance

o Operator documentation describes how to run the

system
o User documentation how to use the program
Converting the system
o Precautions: validation (whether old is correct),
reconciliation (completeness), backup
o Process of converting is called cutover
Cold turkey switches to new, cancels old
Phased converting parts by parts, may cause
incompatibility
Parallel operation two systems going at the
same time
o Auditors role
Externals cannot be involved in the design
Technical expertise, documentation standards,
control adequacy
o Post-implementation review
System design adequacy
Cost/benefit estimates

o Maintenance
May need to undergo changes to accommodate changes to needs

Controlling and auditing the SDLC

Controlling new systems development
o Systems authorization ensure economic justification
o User specifications satisfy needs of all end users
o Technical design technical specifications of a system meets needs of users
o Internal audit participation ensure an effective transfer of knowledge
o User test acceptance testing before implementation
Audit objectives
o Ensure SDLC is in accordance with policies
o Implementation was free of errors
o Testing was done
Audit procedures
o Review authorization process, cost-benefit analysis, feasibility, analysis of
user needs
Source program library (SPL)
o Where all development and maintenance programs are stored, ma nagged by
a SPLMS (management system)
o Controls:
Passwords
Separate libraries
Audit trails and management reports
Program version numbers
Limited access to maintenance commands

o Audit objectives to system maintenance

Detect unauthorized program maintenance
o Procedures
Identify unauthorized changes (program versions)
Identify application errors (reconcile source code, review test results,
retest program)
Test access to library