Information Systems
Control & Audit(3)
Shin, SooJung
Based on Ron’s book
Chapter 4
System Development Management Control
(1) Approaches to auditing system development
(1)
(2)
(3)
Concurrent audit: auditors are member of the system development team
Postimplementation audit: auditors seek to help an organization learn from its
experiences in the development of a specific application system
General audit: auditors evaluate systems development controls overall.(external audit이
주로 시행)
(2) Normative models of the system development process
SDLC Approach
(1) Feasibility study
Cost-benefit
(2) Information
analysis
requirement
(3) System design
(4) Program
development
(5) Procedure &forms
development
(6) Acceptance
testing
(7) conversion
(8) Operation &
Maintenance
(2) Normative models of the system development process
Sociotechnical Design Approach
Sociotechnical design
Technical
Social
System
Management
Of the change
process
Diagnosis &
entry
System
interaction
Social
System
Design
Adjustment of
coordinating
mechanisms
High task
accomplishment
High quality of
Working life
Implementation
Joint optimization
Task
systems
design
(2) Normative models of the system development process
Political Approach
Start
Historical Analysis to
determine power
structure
No
Will
Proposed system
Change power
Structure?
Yes
Face-to-face
negotiation and
compromise
User
Participation
Continue
(2) Normative models of the system development process
Soft-Systems Approach
Take action to
Improve
situation
Recognize the
Problem situation
Express the
Problem situation
Produce root
Definitions of
Relevant systems
Compare
Conceptual models
With problem
situation
Develop conceptual
Models of
Relevant systems
Identify
Desirable
And feasible
changes
(2) Normative models of the system development process
Prototyping Approach
Elicit user
requirement
Design
Prototype
Implement
Prototype
Use
Prototype
Build
Production
System
(2) Normative models of the system development process
Information Engineering Approach
-
전략정보계획에서부터 출발
분석/설계 중심
1. Information
strategic planning
2. Business Area
modeling
3. Business System
Design
4. Technical Design
5. Construction
6. Transition
7. Production
(2) Normative models of the system development process
Contingency Approach
(1)
(2)
(3)
(4)
(5)
(6)
Social system impact: impact가 크면 behavior issue(직무의 재설계 등에 사용자의 참여 등)
들을 고려하고 그렇지 않을 경우 중요하지 않음.
Task systems impact: 시스템이 직무의 수행이나 효과, 효율성에 중심역할을 한다면 전문적인
개발인력이 참여하고 효과적인 커뮤니케이션과 높은 품질의 개발이 이루어져야 하고, 그렇지 않을
경우는 최종사용자에 의해 개발될 수 있음.
System size: 대형시스템일경우 전문적인 개발인력이 참여하고 효과적인 컴뮤니케이션과 높은
품질의 개발이 이루어져야 하고, 그렇지 않을 경우는 최종사용자에 의해 개발될 수 있음.
Commonality: 시스템이 상대적으로 common하고 요구사항이 잘 이해되고 있다면 패키지를
구입할 수 있음. 시스템이 impact가 작다면 사용자가 구입가능하고, 그렇지 않을 경우 정보시스템
전문가가 구입에 역할을 담당함.
Requirements uncertainty: 요구사항이 분명치 않으면 프로토타이핑이 중요하고, 요구사항이 잘
이해되면 프로토타이핑은 불필요함.
Technology uncertainty: 조직의 경험이 부족한 기술을 사용하여 개발한다면 개발의 주요역할은
정보시스템 전문가에 의해 수행되어야 함.
(3) Evaluating the major phases in systems development process
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
Problem/opportunity definition
Management of the change process
Entry and feasibility assessment
Analysis of the existing system
Formulation of strategic requirements
Organizational and job design
Information processing system design
Application software acquisition and development
HW/SW acquisition
Procedure development
Acceptance testing
Conversion
Operation and maintenance
(3) Evaluating the major phases in systems development process
(1)
(1)
(2)
(3)
(4)
Problem/opportunity definition
If possible IS solutions to the problem or opportunity will be material in terms of size or
impact, have formal terms of reference been prepared? If so, have they been approved by a
steering committee or well constituted project committee?
If possible IS solutions will have a major impact on task systems or social systems, what
level of acceptance exists among the stakeholders on the need for change? Do the terms
of reference consider the need for consultation and negotiation ?
If there is a high level of requirements uncertainty or technological uncertainty surrounding
possible solutions to the problem or opportunity, do the terms of reference take into
account strategies that might help alleviate the uncertainty?
Do the stakeholders agree on the definition of the problem or opportunity? If they
disagreed at the outset, what approaches were used to try to reach consensus?
Reach Agreement!
Understand the threat!
(3) Evaluating the major phases in systems development process
(2) Management of the change process
Auditor의 관심: 프로젝트 관리와 변화 과정을 위한 결정의 질을 평가
Project Management
Planning
Analysis
Design
Change facilitation
-unfreezing the organization
-moving the organization
-refreezing the organization
Construction
Implementation
Evaluate quality of decision !
(3) Evaluating the major phases in systems development process
(3) Entry and feasibility assessment
The purpose : is to obtain a commitment to change and to evaluate whether cost-effective
solutions are available to address the problem or opportunity that has been identified.
Auditor의 관심(during): 변화가 사용자들에게 강요되지 않았나?, feasibility 분석이 채택되고 수행되기
위해 적절한 접근이 이루어졌는가?
Auditor의 관심(post): entry 전략과 feasibility assessment의 기법을 선택하기 위해 사용된 프로세스,
entry 전략과 feasibility assessment 이 얼마나 성공적이었는지 평가
Technical
Can the input data be collected for
The system? Output usable?
Is the available technology sufficient to
support the proposed Project?
Operational
What impact ‘ll the system have on
The users’ QWL?
Economic
Behavioral
DO the benefits of the system exceed
the costs?
System development process
(3) Evaluating the major phases in systems development process
(4) Analysis of the existing system
(1)
(2)
history, structure & culture: study를 했는가? 필요한 면이 무엇인가? 어느정도 했는가?
Product & information flow: 조사의 범위와 근원?, 사용한 방법론? CASE Tool의 사용?
OLD SYSTEM
Existing
History, culture
& structure
NEW SYSTEM
Existing
Product & information flow
* 분석방법
- Structured Analysis
- OO Analysis
- SSM
(3) Evaluating the major phases in systems development process
(5) Formulating strategic requirements
(1)
(2)
strategic requirements: the overall goals and objectives the system must accomplish
Auditor: 시스템 설계자가 연속되는 설계작업의 품질을 위해 전략적인 요구사항들을 파악하는
중요성을 이해하고 있는지 파악
(6) Organizational & Job Design
(1)
(2)
-
strategic requirements의 만족을 위해 Organizational & Job redesign필요
Auditor
제안된 시스템이 조직의 구조나 직무에 영향을 줄 경우 시스템 개발팀이 조직의 역사나 실행에
숙련된 전문가로부터 고품질의 어드바이스를 받는지 파악
조직의 구조나 직무설계를 책임지는 인력들이 각 담당자 그룹의 대표를 포함하는지, 설계작업이
어떻게 이행되고 있는지, 갈등이나 불확실성들을 어떻게 해결하는지, 최종적으로 선택되는 설계에
관련된 결론의 레벨이 어느 정도인지를 파악함.
(3) Evaluating the major phases in systems development process
(7) Information processing system design
(1) Auditor
설계가 전략적 요구조건을 만족하는지
시스템내부에 설계된 control의 신뢰성 평가
System의 auditability
(2) 6 major activities
Elicitation of detailed requirements
Design of the data/information flow
Design of DB
Design of UI
Physical design
Design and acquisition of HW/system SW platform
Requirement
elicitation
UI
Design
Data/information
Flow design
SW
platform
Design
Physical
Design
DB
Design
(3) Evaluating the major phases in systems development process
(8) Application software acquisition& development
(1)
(2)
-
구입시
벤더에게 제공되는 요구 스펙의 충분성
소프트웨어 평가 절차의 품질 (소프트웨어의 품질, 벤더 유지보수 및 지원의 충분성)
개발시
설계, 코딩, 컴파일링, 테스팅, 문서화 단계 동안 수행되는 절차의 평가
Client
RFP
Adequacy of requirement spec?
Proposal
Compliance with requirements?
Quality of documentation?
Vendor stability & support?
Nature of contractual obligations?
Vendor
(3) Evaluating the major phases in systems development process
(9) HW/ System SW Acquisition
(1)
-
Auditor
벤더에게 제공되는 요구 스펙의 충분성(RFP)
평가 절차의 품질
벤더의 viability, ongoing support, the availabilty of source code & maintenance support 등의
파악
(10) Procedures Development
(1)
(2)
(3)
-
이 단계에서 설계자는 사용자가 시스템의 계속적인 운영과 유용한 산출물을 얻기 위해 수행해야 할
activity들을 정의해야 한다.
절차개발
Design of procedures
Testing of procedures
Implementation of procedures
Documentation of procedures
Auditor
절차설계의 품질 평가(minimum spec of procedures)
시스템이 behavioral impact를 가져올경우 절차 설계팀에 관련자 대표 포함
절차를 테스트하는데 사용되는 접근법을 평가함.
절차 문서화의 품질을 평가함.
(3) Evaluating the major phases in systems development process
(11) Acceptance Testing
(1)
The purpose: is to identify as far as possible any errors and deficiencies in the system prior
to its final release into production use
(2) 4 Types of testing
program testing: 개별 프로그램을 개발한 프로그래머가 자신의 프로그램의 정확성, 완전성,
효율성을 테스트함.
System testing: 개발팀의 몇몇 팀원들이 여러 프로그램들과 서브 시스템간의 인터페이스가
정확하게 작동하는지 파악하기 위해 전체 시스템을 테스트
User testing: 사용자가 조직구조설계, 직무설계, 시스템 인터페이스, 프로그램, 절차 등 전체
시스템을 테스트
QA testing: 시스템이 표준을 준수하는지 테스트
(3) Auditor
How was the testing process planned
How were test data designed and developed
What test data were used
What test results were obtained
What actions were taken as a result of errors and deficiencies identified
What subsequent modifications to test data were made
How was control exercised over test data and acceptance testing process
Program
test
User Test
Program
test
Program
test
System Test
QA Test
(3) Evaluating the major phases in systems development process
(12) Conversion
(1)
The conversion phase comprises those activities undertaken to place the new system in
operation.
(2) Conversion activities
Personnel training
Installation of new HW & SW
Conversion of files and programs
Scheduling of operations and test running
(3) Auditor
Disruption의 위험
Conversion시기
Trade-off
Careful planning
old
New
old
New
old
New
(3) Evaluating the major phases in systems development process
(13) Operation & Maintenance
In production
Repair maintenance: logic errors discoved in the system are corrected
Adaptive maintenance: changes in the system environment might necessitate system
modification
Perfective maintenance: changes might be made to improve processing efficiency
- formal change process : to identify and record need for changes to a system and to authorize
and control the implementation of needed changes.
(3) Evaluating the major phases in systems development process
(13) Operation & Maintenance(Source Library control)
Systems
Development
programmers
Systems
maintenance
programmers
System Development
Test library
SPL
Application
program
Application
program
System Maintenance
Test library
Application
program
Compile &
Link edit
SPL Management
System
Application
Load module
Maintenance
request
users
-프로그램 저장
-유지보수를 위해
프로그램 추출
-라이브라리에서
프로그램제거
-프로그램변경 문서화
Program
Listing
Program
Change
report
Documentation
file
Production