Controls design Controls are “the plan of organization and all the methods and measures to safeguard its assets, check the accuracy and reliability of.

Controls design

• Controls are • “the plan of organization and all the

methods and measures to safeguard its assets, check the accuracy and reliability of its accounting data, promote operational efficiency, and encourage adherence to prescribed managerial policies” (AICPA)

• They can be preventive, detective or corrective• They can be manual or automated

Traditional Control mechanisms• separation of duties

• controlling access to assets

• audit trail 

• capture and storage of events in multiple locations and time periods (duplication)

• system of authorizations

• Too many controls will reduce efficiency; too few controls will reduce effectiveness

Effect of computers on controls

• No clear separation of duties– many different activities are placed in the same

location, done at the same time, by the same unit (program).

– multiple users use the program– decline in accountability (analyst?, programmer?,

quality assurance?, user?)

• Access to assets threatened– information systems concentrate the organizational

assets– several people have access; high potential for abuse– greater exposure of data assets due to communication

networks 

• Tighter integration as opposed to duplication– Databases– workflow automation (ERP) systems

IT control principles• 1. focus should be on prevention than

detection because detection is expensive in a complex IT environment; also, the loss due to an error is significant– emphasis should be placed on the design stage– testing prior to production should be rigorous

• 2.   use IT and its capabilities to tailor control procedures to the business processmanual control procedures are likely to be

ineffective in a complex IT driven system

IT Control principles

• 3.   an electronic audit trail is more effective than a paper-based audit trail.

• 4. It is better to “build-in” controls rather than “build-on” top of existing process structure.

IT Controls• Input

• Process

• Output

• Communication

• Database

• Interface Controls 

INPUT CONTROLS 

• Factors to consider in the evaluation of input controls– Extent of human intervention

– Time lapse between the occurrence of event and the input activity

•  Data Capture Controls• Source Document and Data Entry Screen Designs•  Source Document Design

– Pre-numbering documents

– Preprinting documents

Use of Codes

• Codes should be compact, meaningful, flexible, and stable

• Serial (sequence) Codes– Captures history without the need for a time stamp– Example: check numbering

•  Block Sequence Codes– Serial coding within blocks (categories) of data– Example: 11040101, 11040102, …

•  Association Codes– Derived by concatenating codes of different attributes

of the entity– Example: UGBSEE for Undergraduate BS in EE major

•  Check Digits

Batch Controls• Detect errors in physical transmission, and

data entry stages •  Some of the controls include•  Record Count•  Batch Total of a data item•  Hash total of a data item• Batch Size

– Large: Problems with correction if there is an error

– Small: Too many batches, Too many calculations of batch total, more processing in general

Data Validation Controls

•  Field Checks– Null, Type, Size, Format, Range, Legal Values,

Check Digit, Referential Integrity

•  Record Checks– Consistency among data items in a record,

Duplicates, Missing Records

• Audit Trail– Data gathering stage– Data entry stage– Who, when, device, file/record updated

Output Controls• Controls to make sure that the required output is

produced and distributed to the appropriate destinations in a timely manner

• Output Production and Distribution• Key Stages• Storage of supplies such as preprinted forms• Execution of report programs• Queuing/Spooling• Printing• Output collection and distribution• Output storage and retention• Output disposal

Process controls

• walk-throughs,

• code inspection

• testing

• Simulation

Chapter 15: Construction

• We will focus on test design rather than the actual construction and documentation of the system.

Designing Tests

• The purpose is not to demonstrate that the system is free of errors;

• The purpose is to detect as many errors as possible

Testing Philosophy

• It is dangerous to test early modules without an overall testing plan

• It may be difficult to reproduce sequence of events causing an error

• Testing must be done systematically and results documented carefully

– Regression Errors

Stages of Testing• Unit testing

– Tests each module to assure that it performs its function

• Integration testing

– Tests the interaction of modules to assure that they work together

• System testing

– Tests to assure that the software works well as part of the overall system

• Acceptance testing

– Tests to assure that the system serves organizational needs

Error Discover Rates

Test Planning

• Driver and Stub Technique• Driver

– The main testing program

– It calls the module to be tested, passes the test data, collects and stores results

• Stub– The module being tested

Unit Testing

• Black Box Testing– Focuses on whether the unit meets requirements stated

in specification

• White-Box Testing– Looks inside the module to test its major elements

Integration Testing

• User interface testing

– Tests each interface function

• Use-case testing

– Ensures that each use case works correctly

• Interaction testing

– Tests each process in a step-by-step fashion

• System interface testing

– Ensures data transfer between systems

System Testing

• Requirements Testing

– Ensures that integration did not cause new errors

• Usability Testing

– Tests how easy and error-free the system is in use

• Security Testing

– Assures that security functions are handled properly

• Performance Testing

– Assures that the system works under high volumes of activity

• Documentation Testing

– Analysts check that documentation and examples work properly

Acceptance Testing

• Alpha Testing– Repeats tests by users to assure they accept the

system

• Beta Testing– Uses real data, not test data

Generating Test Data

• Historical Transaction Data

• Data derived from Data Dictionary

• Data derived from program logic and structure

Data from Program Logic and Structure

• Focus is on program graph

• Statement Coverage

• Branch Coverage

• Path Coverage

• Example

Example• (1)Read wage• (2)If wage < 15000 then• (3)Fedtax = wage*0.15• Else• (4)If Wage < 50000 then• (5) Fedtax = (15000*0.15) + (wage-15000)*0.28• Else• (6) Fedtax = (15000*0.15) + (35000*0.28) + (wage-50000)*0.31• End if• Endif• (7)If wage < 10000 then• (8)Statetax = wage*0.04• Else• (9)If wage < 40000 then• (10) Statetax = (10000*0.04) + (wage-10000)*0.05• Else• (11) If wage < 75000 then• (12) Statetax = (10000*0.04) + (30000*0.05) + (wage-40000)*0.06• Else• (13) Statetax = (10000*0.04) + (30000*0.05)+ (35000*0.06)+• (wage-40000)*0.07• EndIf• End if• Endif• (14)Totaltax = Fedtax + StateTax• (15)NetSalary = Wage-Totaltax• (16)Print Wage, FedTax, StateTax, NetSalary