Anda di halaman 1dari 37

Fasilkom UI


Systems Development (SD) and

Management Controls

SD management has responsibility for those

functions concerned with IS :
 analyzing / designing,
 building / implementing
 and maintaining
Art rather than science
Auditors can conduct three types
of reviews of the SD process
Major approaches to SD
Tasks in SD and controls over tasks
Approaches to Auditing SD
 Concurrent Audit - Participate as a team member
 Early correction of errors versus independence
 What should happen? What has happened?
 Ex Post audit - Post-implementation review
 What went right / wrong during the process?
 Likely strengths and weaknesses of the system?
 System scrapped, continued , modified?
 General audit - Evaluate SD
process in general
 Can we reduce the extent
of substantive testing?
Normative Models
of the SD Process
Model for Systems Actual Practice

Discrepancies and inefficient

or ineffective controls

 Systems development life cycle approach

 Socio-technical design approach
 Political approach
 Soft-systems approach
 Prototyping approach
 Contingency approach
Systems Development
Life Cycle Approach
 Application of Project management techniques
 Each phase should:
 be planned and controlled
 comply with development standards Plans
 be adequately documented Plans
 be staffed by competent employees
 have project checkpoints and signoffs
 Phases can occur concurrently Milestones
 Phases can be iterated


Systems Development
Life Cycle Approach
Feasibility Study

Information Analysis

Systems Design

Program Development

Procedures and Forms Development

Acceptance Testing


Operation and Maintenance

Socio-technical Design
 Avoid Resistance / sabotage with SDLC (user oriented)
 Impact on organization structure design

Social Technical
system system • Diagnosis and Entry
• Management of the
Change Process
• System Design (Technical
High quality High Task and social)
of life Accomplishment • Adjust Coordinating
• Implementation
Political Approach
Historical analysis to determine
 IS changes power power structure

 IS - influence others
 IS - symbolic power
 involve users when No proposed system
power structure intact change the power
 Replace involvement
with negotiation
 Users undermine
progress User Face to face negotiation and
 Confront users participation compromise

 Powerful ‘fixer’
Soft-systems approach
Recognize the problem situation
 problem solver
 problem owner
 decision taker (power)
Express the problem situation
 roles, norms and values
 rich pictures
Produce root definitions of relevant systems
 customers, actors and transformations, owner,
and environment (CATWOE)
Soft-systems approach
Develop conceptual models of relevant systems
 ‘systems thinking’
 ideal model
Compare conceptual models
with perceived problem situation
 exploration
 diagnosis
 design
Identify desirable and feasible changes
Take action to improve the problem situation
Soft systems approach

Recognize the Take action

situation Identify desirable
and feasible
Express the changes
conceptual model
and problem Real World

Systems Thinking

Produce root Develop conceptual

definitions models of relevant
Prototyping approach Elicit user

 Powerful low-cost microcomputers

 End-user development Design
 Powerful high-level, end-user programming
 users develop their own systems Implement
 rapid development of prototypes prototype
 Users have a central role in systems
 strategic and decision support systems Use prototype
 Rapid iteration between alternate designs
 Inefficiency overcome by faster hardware
or reprogramming
Build production
*Do end users have sufficient knowledge to design and system
implement high-quality information systems
Contingency approach
Social systems impact
Tasks systems impact
Systems size
Requirements uncertainty
Technology uncertainty

Identify the factors with the most impact on the

development process

Decide on the best development approach

Evaluating the Major Phases
of The SD Process
 What basis can auditors use to evaluate the process?
 How can they obtain assurance about the quality of the
information systems when the development process is
widely dispersed?
 How can they rely on controls when in some cases
developers and users take for granted that they do not
fully understand the nature of the systems they are
trying to develop?
 Assume a common list of phases - agenda of issues for
stakeholders (designers, users, management)
 Quality related to success with issues
Evaluating the Major
Phases of The SD Process (1)
Problem / opportunity definition
Management of the change process
Entry and feasibility assessment
Analysis of the existing system
Studying the existing organizational history,
structure, and culture.
Formulating strategic requirements
Organizational and job design
Evaluating the Major
Phases of The SD Process (2)
Information processing systems design
Elicitation of detailed requirements
Design of the data/information flow
Design of the database
Design of the user interface
Physical design
Design of the hardware /system software platform
Evaluating the Major
Phases of The SD Process (3)
Application software acquisition and development
Hardware/system software acquisition
Procedures development
Acceptance testing
Operations and maintenance
Auditor’s Consideration

How does the conduct of each phase vary

depending upon:
 the system’s task and social impact?
 the size of the system
 the commonality of the system?
 the requirements and technological uncertainty?
How will controls differ depending upon the
levels of these contingent factors?
Problem / opportunity definition
 Stakeholder concerns about -> Nature of the problem
 Structured? Scope? Definition clear? Impact of structures and jobs?
New technology?
 Auditors concerns about the activities carried out:
 Large systems ?-> Are there formal terms of reference approved by
steering/project committee?
 Large impact on tasks or social systems? - Acceptance levels high
among stakeholders? -> Need for negotiation and consultation?
 High levels of requirements or technological
uncertainty? -> Strategies to alleviate uncertainty?
 Do stakeholders agree on problem definition?
-> Approaches to reach consensus?
Management of the
change process
Change facilitating activities parallel project
management activities
 Unfreezing the organization - education,
feedback, participatory decision making
 Moving the organization
 Refreezing the organization - positive feedback
 Negotiation and compromise
Auditors evaluate the quality of decisions made
about project management and change
facilitation - contingency perspective
Entry and feasibility
 Technical feasibility:Technology acquired or developed?
 Operational feasibility: Input data available? Output useable?
 Economic feasibility: Benefits exceed costs?
 Behavioral feasibility: Impact on quality of user’s life





Systems development process

Stop Go
Analysis of the existing system
Studying the existing organizational history,
structure, and culture
Studying the existing product and information flows
Evaluate designers
decisions about what History Old System
needed to be studied
and to what extent
Nature and extent of
examination Structure
High-quality New System
Product Flows
Computer aided software
engineering tools CASE

Information Flows
Formulating strategic
Auditors evaluate:
Vague or specific?  Do systems designers recognize the
importance of articulating strategic
Early or late? requirements for the quality of
subsequent design work?
 If there are substantial behavioral
Strategic requirements are identified
impacts, are there procedures in place to
based on : reach agreement on strategic
• perceived deficiencies in the existing requirements?
system If substantial uncertainty surrounds the
• perceived opportunities for proposed system, they should examine
enhanced task accomplishment and and evaluate the procedures to help
quality of working life. clarify strategic requirements.
Organizational and job design

Redesign of jobs and structures

Match with strategic requirements
Behavioral problems of change
Auditors evaluate:
 advice sought from experts?
 Redesign included stakeholder representatives
 Consensus reached and conflict avoided?
 Impact on control risk?
Information processing
systems design
Data and Information
Flow design

User Interface
Software design

Platform Design
Elicitation of detailed
Ask the stakeholders what they require
Discover the requirements through analysis and
• Have designers chosen
appropriate requirements-
elicitation strategies, and
• Evidence of satisfactory
consensus and
Design of the
data/information flow
The flow of data and information and the
transformation points
The frequency and timing of the data and
information flows
The extent to which data and information will be

Evaluate the activities carried

out – does the design meet
Design of the database
 Conceptual modeling – entities/objects, attributes, relationships, static
and dynamic constraints, triggers and business rules
 Data modeling – relational or other data model to permit manipulation
by SQL and program languages.
 Storage structure design – records, tuples, relationship structures and
 Physical layout design – storage media, locations, client/server,
internet, enterprise systems

Auditors should evaluate:

Database scope
Was the structure designed using well known
database design methodologies?
Case tools used during the design?
Design of the user interface
 Source documents to capture raw data
 Hard copy output reports
 Screen layouts for dedicated source document input
 Inquiry screens
 Command languages
 Interrogation languages
 Graphical and color displays
 Voice input or output Auditors should evaluate:
 Light pen or mouse Critical activity – major source of
 Icons control as users interact with the
Validation, error control
Good design practices followed?
Adequate testing?
Physical design

Batch / on-line / real time
Design of the hardware /system software
platform Auditors should evaluate:
Efficiency and effectiveness
Good design practices followed?
Adequate testing?
Modularity and generality– ease of
upgrade and change
Quality of connections and
Application software
acquisition and development
 Software acquired or developed
 Generalized packages configured and perhaps modified and adapted.
 Prototyping
 SDLC and program development from scratch –n see next chapter.
Auditors should evaluate:
Acquired software
 Quality of specifications to vendors
 Quality of procedures to evaluate software: functionality, accuracy,
completeness, documentation, vendor stability and support, nature of
Quality of software and maintenance
Developed software
 Procedures during developme4n see next chapter
Control risks during development
Testing and implementation
 Insertion of audit routines and modules
Hardware/system software acquisition

Purchased hardware
Request for proposal
Vendor submission evaluated
Selection process

Auditors should evaluate:

Evidence of above process
Review documentation
Quality of hardware acquired
Procedures development

Design of procedures
Testing of procedures
Implementation of procedures
Documentation of procedures
Auditors should evaluate:
Quality of procedures design
Compliance obtained – stakeholders represented.
Approach to testing of procedures
Quality of procedures documents
Acceptance testing
Identify errors and Program testing
deficiencies in the system System testing
User Testing
Need a plan Quality assurance testing
Can’t be complete Auditors should evaluate:
How was the testing process
comprehensive planned?
How were the test data designed and
 Number of execution paths developed?
 Need experience with the system What test data were used?
What test results were obtained?
 Many conditions can’t be simulated What actions were taken as result of
 Difficulty of determining correctness errors or deficiencies identified?
What subsequent modifications to test
 Cost data were made in the light of testing
How was control exercised over test
data and acceptance testing process?

Steps to place the new system in operation

 Abrupt changeover
 Phased changeover
 Parallel changeover

Personnel training
Installation of new hardware and software
Conversion of files and programs
Schedule of operations and test running
Operations and maintenance

Repair maintenance
 Logic system
Adaptive maintenance
 System environment Change
Perfective maintenance
 Improve processing efficiency