You are on page 1of 58

SYSTEMS DEVELOPMENT AND

PROGRAM CHANGE ACTIVITIES


CHAPTER V

EARL KYSTER DEYPALUBOS


HERWIN MAE BOCLARAS
PARTICIPANTS IN SYSTEMS DEVELOPMENT

 System professionals are systems analysis,


systems engineers, and programmers.
 End users are those for whom the system is
built.
 Stakeholders are individuals either within or
outside the organization who have an interest
in the system but are not end users.
 Accountants/Auditors are those professionals
who addresses the controls, accounting, and
auditing issues for systems development.
WHY ARE ACCOUNTANTS AND AUDITORS INVOLVED
WITH SDLC?

 The creation of an information system entails


significant financial transactions.
 The nature of the products that emerge from
the SDLC.
HOW ARE ACCOUNTANTS INVOLVED WITH SDLC?

 Accountants are users.


 Accountants participate in systems
development as members of the development
team.
 Accountants are involved in systems
development as auditors.
INFROMATION SYSTEMS ACQUISITION

develop customized systems in-


purchase commercial systems from
house through formal systems
software vendors
development activities
In-House Development
firms design their own information system
Commercial Systems
a growing number of systems are purchased from software vendors
FOUR FACTORS HAVE STIMULATED THE GROWTH OF THE
COMMERCIAL MARKET

 relatively low cost of general commercial software as


compared to customized software;
 emergence of industry-specific vendors who target their
software to the needs of particular types of businesses;
 growing demand from businesses that are too small to
afford in-house systems’ development staff; and
 trend toward downsizing of organizational units and
the resulting move toward the distributed data
processing environment, which has made the
commercial software option more appealing to larger
organizations
TYPES OF COMMERCIAL SYSTEMS
 Turnkey systems - completely finished and tested
systems that are ready for implementation
 General Accounting systems - designed to serve a wide
variety of user needs
 Special-Purpose systems – created to target selected
segments of the economy
 Office Automation system - computer systems that
improve the productivity of office workers
 Backbone systems - provide a basic system structure on
which to build
 Vendor-Supported Systems - hybrids of custom systems
and commercial software
ADVANTAGES DISADVANTAGES

implementat independe
ion time nce

need for
cost customize
d system

maintenan
reliability ce
THE SYSTEMS DEVELOPMENT LIFE CYCLE

 new systems development involves conceptual


steps that can apply to any problem-solving
process:
 identify the problem,
 understand what needs to be done,
 consider alternative solutions,
 select the best solution, and, finally,
 implement the solution
 systems maintenance, constitutes the
organization’s program change procedures
SYSTEMS PLANNING – PHASE I
OBJECTIVE:
to link individual system projects or applications to the
strategic objectives of the firm
who should do systems planning
steering committee:
• chief executive officer
• chief financial officer

• chief information officer

• senior management from user areas

• internal auditor

• senior management from computer services


typical responsibilities for a steering committee
• resolving conflicts that arise from new systems
• resolving projects and assigning priorities

• budgeting funds for systems

• reviewing the status of individual projects under

development
• determining at various checkpoints throughout the SDLC

whether to continue with the project or terminate it


systems planning occurs at two levels
strategic systems planning project planning
 involves the allocation → the purpose of project planning is
to allocate resources to
of systems resources at individual applications within
the macro level the framework of the strategic
 usually deals with a plan
 identifying areas of user
time
Why frame of 3 to 5
WhyPerform
PerformStrategic
StrategicSystems
Systems needs,
years Planning?
Planning?  Preparing proposals,
 evaluating each proposal’s
AAplan
planthat
thatchanges
changesconstantly
constantlyisis feasibility and contribution to
better
betterthan
thanno
noplan
planatatall
all the business plan,
Strategic
Strategicplanning
planningreduces
reducesthethecrisis
crisis  prioritizing individual
component
componentin insystems
systemsdevelopment
development projects, and
Strategic
Strategicsystems
systemsplanning
planningprovides
provides  scheduling the work to be
authorization
authorizationcontrol
controlforforthe
theSDLC
SDLC done
Cost
Costmanagement
management
product of this phase consists of two formal documents

the project proposal the project schedule


→ provides management → represents management’s
with a basis for deciding commitment to the project
whether to proceed with the
project

Auditor’s role in systems planning

routinely examine the systems planning phase of the SDLC


SYSTEMS ANALYSIS – PHASE II
 a two step process involving first a survey of
the current system and then an analysis of the
user’s needs
 deliverable from this phase is a formal systems
analysis report, which presents the findings of
the analysis and recommendations for the new
system
THE SURVEY STEP
the analyst often begins the analysis by determining what elements, if any, of
the current system should be preserved as part of the new system

advantages
advantages

 identifying
identifyingwhat
what
disadvantages
disadvantages aspects
aspectsofofthe
theold
old
system
systemshould
shouldbe bekept
kept
 current
currentphysical
physicaltar
tar
pit
pit  forcing
forcingsystems
systems
analysts
analyststo
tofully
fully
 thinking
thinkinginside
insidethe
the understand
understandthe
thesystem
system
box
box
 isolating
isolatingthe
theroot
rootof
of
problem
problemsymptoms
symptoms
gathering facts
Data sources - these include external entities, such as customers or
vendors, as well as internal sources from other departments.
Users. These include both managers and operations users.
Data stores - the files, databases, accounts, and source documents used in
the system.
Processes - tasks are manual or computer operations that represent a
decision or an action triggered by information
Data flows - represented by the movement of documents and reports
between data sources, data stores, processing tasks, and users.
Controls - include both accounting and operational controls and may be
manual procedures or computer controls.
Transaction volumes - analyst must obtain a measure of the transaction
volumes for a specified period of time
Error rates - transaction errors are closely related to transaction volume
Resource costs - resources used by the current system include the costs of
labor, computer time, materials (such as invoices), and direct overhead
Bottlenecks and redundant operations - analyst should note points
where data flows come together to form a bottleneck
Fact-Gathering Techniques
 Observation
 Task Participation
 Personal Interviews
→ open –ended questions
→ questionnaires
 Reviewing Key Documents

Auditor’s role in systems analysis

accountant/auditor should be involved in the needs analysis of the


proposed system to determine if it is a good candidate for advanced
audit features and, if so, which features are best suited for the system
reviewing key documents
 organizational charts
 job descriptions

 accounting records

 charts of accounts

 policy statements

 description of procedures

 financial statements

 performance reports

 system flowcharts

 source documents

 transaction listings

 budgets

 forecasts

 mission statements
CONCEPTUAL SYSTEMS DESIGN – PHASE III
PURPOSE:
to produce several alternative conceptual systems that satisfy
the system requirements identified during systems analysis
two approaches to conceptual systems design
the structured approach the object-oriented approach

→ develops each new system from → from the bottom up through the
scratch from the top down assembly of reusable modules rather than
create each system from scratch

Auditor’s role in conceptual systems design


auditor is a stakeholder in all financial systems and, thus, has an interest in
the conceptual designs that will go to the detailed design phase
SYSTEM EVALUATION AND SELECTION—PHASE IV
 an optimization process that seeks to identify the best system
 involves two steps:
1. Perform a detailed feasibility study →
technical, economic, legal, operational, and
schedule
2. Perform a cost-benefit analysis
→ three steps in the application of cost-benefit
analysis
1. identify costs
2. identify benefits
3. compare costs and benefits
identify costs
one method of identifying costs is to divide them into two
categories:
> one time costs
hardware acquisition
site preparation
software acquisition
system design
programming and testing
data conversion
training

> recurring costs


hardware maintenance
software maintenance
insurance
supplies
personal costs
identify benefits
tangible benefits fall into two categories:
> increased revenues
increased sales within existing market
expansion into other markets

> cost reduction


labor reduction
operating cost reduction
reduced inventories
less expensive equipment
reduced equipment maintenance
identify benefits
intangible benefits fall into two categories:
> often of overriding importance in information system
decisions
> they cannot be easily measured and quantify
compare costs & benefits
two most common methods used for evaluating information
systems:
> net present value method
> payback method
DETAILED DESIGN – PHASE V
PURPOSE:
to produce a detailed description of the proposed system that
both satisfies the system requirements identified during systems
analysis and is in accordance with the conceptual design

PERFORM A SYSTEM DESIGN REVIEW SYSTEM


WALKTHROUGH DOCUMENTATION
 ensure that the design are free from  at this point, a decision is made either
conceptual errors that could become to return the system for additional design
programmed into the final system or to proceed to the next phase-system
coding and testing
 conducted by a quality assurance group
APPLICATION PROGRAMMING AND TESTING –
PHASE VI

PROCEDURA ●
Require the programmer to specify the precise
L order in which the program logic is executed.

Often called third-generation languages (3GIs)
LANGUAGE


No longer procedural, under this model, the program’s
EVENT-DRIVEN code is not executed in a predetermined sequence.
Instead, external auditor or events that are initiated by the
LANGUAGE

user to dictate the control flow of the program.


Central in achieving the benefits of the object
OBJECT-ORRIENTED oriented approach is developing software in an
LANGUAGE objective-oriented programming language.

The learning curve of OOP languages is deep
PROGRAMMING THE TEST THE APPLICATION
SYSTEM SOFTWARE

 PROGAMMING EFFICIENCY  TESTING METHODOLOGY


> structured steps to follow
> modules van be coded and  TESTING OFFLINE BEFORE
tested independently, which
DEPLOYING ONLINE
reduces programming time
> implementing a system
 MAINTENANCE EFFICIENCY
without testing offline is an
> small modules are easily to invitation go disaster
analyze and change which reduces  TEST DATA
the start-up time during program
maintenance > extremely time consuming
aspect of program
 CONTROL
> this activity can, however,
> by keeping modules small,
provide future
they are less likely to contain
material errors
SYSTEM IMPLEMENTATION – PHASE VII
 Database structures are created and populated with data,
equipment is purchased and installed, employees are trained, the
system is documented, and the new system is installed
 Testing the Entire System
 Documenting the System
> designer and programmer documentation
> operator documentation
> user documentation
> user handbook
 Converting the Databases
Designer and Programmer Documentation
systems designers and programmers need documentation
to debug errors and perform maintenance on the system
Operator Documentation
computer operators use documentation called a run manual,
which describes how to run the system.
the typical contents of a run manual include:
User Documentation
• users need documentation describing how to use the system
• user tasks include such things as entering input for transactions,

making inquiries of account balances, updating accounts, and


generating output reports
• the nature of user documentation will depend on the user’s degree

of sophistication with computers and technology.


• thus, before designing user documentation, the systems

professional must assess and classify the user’s skill level.


• the following is one possible classification scheme
User Handbook
• with these classes in mind, user documentation often takes the
form of a user handbook, as well as online documentation
• the typical user handbook will contain the following items:
Tutorials
• online tutorials can be used to train the novice or the occasional
user
• the success of this technique is based on the tutorial’s degree of

realism
• tutorials should not restrict the user from access to legitimate

functions

Help Features
• online help features range from simple to sophisticated
• a simple help feature may be nothing more than an error message

displayed on the screen


• the user must “walk through” the screens in search of the solution

to the problem
• more sophisticated help is context-related

• when the user makes an error, the system will send the message,

“Do you need help?”


• the help feature analyzes the context of what the user is doing at

the time of the error and provides help with that specific function
(or command).
converting the database
Database conversion is a critical step in the implementation
phase.

The following precautions should be taken:

 Validation. The old database must be validated before


conversion. This requires analyzing each class of data to
determine whether it should be reproduced in the new
database.

Reconciliation. After the conversion action, the new database


must be reconciled against the original. Sometimes this must be
done manually, record by record and field by field. In many
instances, this process can be automated by writing a program
that will compare the two sets of data.

Backup. Copies of the original files must be kept as backup


against discrepancies in the converted data. If the current files
are already in magnetic form, they can be conveniently backed
up and stored. However, paper documents can create storage
problems. When the user feels confident about the accuracy and
completeness of the new databases, he or she may destroy the
paper documents.
converting to the new system
the process of converting from the old system to the new one is called the
cutover


switch to the new system all at once
cold turkey ●
simultaneously terminate the old system
riskiest approach

modules are implemented in a piecemeal


phased

fashion


the old system and new system are run
parallel operation simultaneously for awhile
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

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 documents standards for auditing purpose
• verifying control adequacy in accordance with SAS 78
SYSTEM MAINTENANCE – PHASE VIII
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
CONTROLLING AND AUDITING THE SDLC
maintenance and support
 A materially flawed financial application can corrupt financial
data, which are then incorrectly reported in the financial
statements. Therefore, the accuracy and integrity of the IS
directly affects the accuracy of the client’s financial data.
 A properly functioning systems development process ensures that only
needed applications are created, that they are properly specified, that they
possess adequate controls, and that they are thoroughly tested before being
implemented.
 The systems maintenance process ensures that only legitimate changes are
made to applications and that such changes are also tested before being
implemented.

If else, application testing and substantive testing is in place.


controlling new system development

 Systems Authorization Activities


 User Specification Activities

 Technical Design Activities

• Documentation is evidence of controls.


• Documentation is a control.

 Internal Audit Participation


 User Test and Acceptance Procedures
 Audit objectives
 Audit procedures
controlling system maintenance

 Four minimum controls:


• Formal authorization
• Technical specifications
• Retesting
• Updating the documentation

when maintenance cause extensive changes to program


logic additional control such as involvement of internal
auditor and user, acceptance testing may be needed
controlling system maintenance

 source program library (SPL) controls


• Why? What trying to prevent?
• Unauthorized access
• Unauthorized program changes
• SPLMS

 SPLMS controls
• Storing programs on the SPL
• Retrieving programs for maintenance purposes
• Detecting obsolete programs
• Documenting program changes
controlled SPL environment

 password control
• On a specific program
 separate test libraries
 audit trail and management reports

• Describing software changes

 program version numbers


 controlling access to maintenance (SPL) commands
audit objectives & procedures
 audit objectives
• Detect any unauthorized program maintenance
• Verify that maintenance procedures protect applications
from unauthorized changes
• Verify applications are free from material errors
• Verify program libraries are protected from unauthorized
access
 audit procedures
• Fig. 4-14, p. 179
• Identify unauthorized changes
 reconcile program version numbers
 confirm maintenance authorization
• Identify application errors
 reconcile source code (after taking a sample)
 review test results
 Retest the program
• Testing access to libraries
 review programmer authority tables
 test authority table
END…

You might also like