Systems Development SD and Management Controls

1
Systems Development (SD) and Management Controls

• Chapter 4

2
Introduction

• 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

3
Approaches to Auditing SD

• Concurrent Audit - Participate as a team member
• Early correction of errors versus independence
• What should happen? What has happened?
  Corrections?
• 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?

4
Normative Models of the SD Process
Actual Practice
Model for Systems Development
Discrepancies and inefficient or ineffective
controls

• Systems development life cycle approach
• Socio-technical design approach
• Political approach
• Soft-systems approach
• Prototyping approach
• Contingency approach

5
Systems Development Life Cycle Approach

• Application of Project management techniques
• Each phase should
• be planned and controlled
• comply with development standards
• be adequately documented
• be staffed by competent employees
• have project checkpoints and signoffs
• Phases can occur concurrently
• Phases can be iterated

Plans
Plans
Schedules/ Milestones
Documentation
6
Systems Development Life Cycle Approach
Feasibility Study
Information Analysis
Systems Design
Program Development
Procedures and Forms Development
Acceptance Testing
Conversion
Operation and Maintenance
7
Socio-technical Design Approach

• Avoid Resistance / sabotage with SDLC
• Impact on organization structure design

• Steps
• Diagnosis and Entry
• Management of the Change Process
• System Design (Technical and social)
• Adjust Coordinating Mechanisms
• Implementation

8
Political Approach
Start
Historical analysis to determine power structure

• ST - involve users
• Users undermine progress
• IS changes power
• IS - influence others
• IS - symbolic power
• Replace involvement with negotiation
• Confront users
• Powerful fixer

Will proposed system change the power structure?
Yes
No
User participation
Face to face negotiation and compromise
Continue
9
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,
  Weltanschauung, owner, and environment (CATWOE)

10
Soft-systems approach

• Develop conceptual models of relevant systems
• systems thinking
• ideal model
• Compare conceptual modelswith perceived problem
  situation
• exploration
• diagnosis
• design
• Identify desirable and feasible changes
• Take action to improve the problem situation

11
Soft systems approach
Real World
Take action
Recognize the problem situation
Identify desirable and feasible changes
Express the problem situation
Compare conceptual model and problem
Systems Thinking
Produce root definitions
Develop conceptual models of relevant systems
12
Prototyping approach
Elicit user requirements

• Powerful low-cost microcomputers
• End-user development
• Powerful high-level, end-user programming
  languages
• users develop their own systems
• rapid development of prototypes
• Users have a central role in systems development
• strategic and decision support systems
• Rapid iteration between alternate designs
• Inefficiency overcome by faster hardwareor
  reprogramming

Design prototype
Do end users have sufficient knowledge to design
and implement high-quality information systems
Implement prototype
Use prototype
Build production system
13
Contingency approach

• Social systems impact
• Tasks systems impact
• Systems size
• Commonality
• Requirements uncertainty
• Technology uncertainty

Identify the factors with the most impact on the
development process Decide on the best
development approach
14
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

15
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

16
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

17
Evaluating the Major Phases of The SD Process (3)

• Application software acquisition and development
• Hardware/system software acquisition
• Procedures development
• Acceptance testing
• Conversion
• Operations and maintenance

18
Auditors Consideration

• How does the conduct of each phase vary depending
  upon
• the systems 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?

19
Problem / opportunity definition

• Stakeholder concerns about -gt Nature of the
  problem
• Structured? Scope? Definition clear? Impact of
  structures and jobs? New technology?
• Auditors concerns about the activities carried
  out
• Large systems ?-gt Are there formal terms of
  reference approved by steering/project committee?
• Large impact on tasks or social systems? -
  Acceptance levels high among stakeholders? -gt
  Need for negotiation and consultation?
• High levels of requirements or technological
  uncertainty? -gt Strategies to alleviate
  uncertainty?
• Do stakeholders agree on problem definition? -gt
  Approaches to reach consensus?

20
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

21
Entry and feasibility assessment

• Technical feasibilityTechnology acquired or
  developed?
• Operational feasibility Input data available?
  Output useable?
• Economic feasibility Benefits exceed costs?
• Behavioral feasibility Impact on quality of
  users life

Technical
Operational
Economic
Behavioral
Systems development process
Go
Stop
22
.
Analysis of the existing system

• Studying the existing organizational history,
  structure, and culture
• Studying the existing product and information
  flows

Old System
Auditors Evaluate designers decisions about what
needed to be studied and to what extent Nature
and extent of examination High-quality
methodology Computer aided software engineering
tools CASE
Culture
New System
History
Structure
Product Flows
Information Flows
23
Formulating strategic requirements

• Vague or specific?
• Early or late?

• Auditors evaluate
• Do systems designers recognize the importance of
  articulating strategic requirements for the
  quality of subsequent design work?
• If there are substantial behavioral impacts, are
  there procedures in place to reach agreement on
  strategic requirements?
• If substantial uncertainty surrounds the proposed
  system, they should examine and evaluate the
  procedures to help clarify strategic requirements.

Strategic requirements are identified based on
perceived deficiencies in the existing system or
perceived opportunities for enhanced task
accomplishment and quality of working life.
24
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?

25
Information processing systems design
Data and InformationFlow design
User Interface Design
Database design
Software
Platform Design
Requirements Elicitation
26
Elicitation of detailed requirements

• Ask the stakeholders what they require
• Discover the requirements through analysis and
  experimentation

Have designers chosen appropriate
requirements-elicitation strategies, and
methodologies. Evidence of satisfactory consensus
and documentation?
27
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
  formalized

Evaluate the activities carried out does the
design meet requirements.
28
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 pointers
• 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?

29
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
• Light pen or mouse
• Icons

• Auditors should evaluate
• Critical activity major source of control as
  users interact with the system.
• Validation, error control
• Good design practices followed?
• Adequate testing?

30
Physical design

• Hardware
• Batch / on-line / real time
• Cycle
• 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 communication

31
Application software acquisition and development

• 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 contracts
• 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

• Software acquired or developed
• Generalized packages configured and perhaps
  modified and adapted.
• Prototyping
• SDLC and program development from scratch n see
  next chapter.

32
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
33
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
34
Acceptance testing

• Identify errors and deficiencies in the system
• Need a plan
• Cant be complete
• Number of execution paths
• Need experience with the system
• Many conditions cant be simulated
• Difficulty of determining correctness
• Cost

Auditors should evaluate How was the testing
process planned? How were the test data designed
and developed? What test data were used? What
test results were obtained? What actions were
taken as result of errors or deficiencies
identified? What subsequent modifications to test
data were made in the light of testing
experience? How was control exercised over test
data and acceptance testing process?
Program testing System testing User
Testing Quality assurance testing
35
Conversion

• 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
36
Operations and maintenance

• Repair maintenance
• Adaptive maintenance

37
COBIT Guidleines
38
Planning Organization Define a Strategic
Information Technology Plan
39
PO1 Maturity Model