Information Systems Control & Audit(3) Shin, SooJung Based on Ron’s book

Information Systems Control & Audit(3)

Shin, SooJung

Based on Ron’s book

Chapter 4System Development Management Control

(1) Approaches to auditing system development

(1) Concurrent audit: auditors are member of the system development team(2) Postimplementation audit: auditors seek to help an organization learn from its

experiences in the development of a specific application system(3) General audit: auditors evaluate systems development controls overall.(external audit 이

주로 시행 )

(1) Concurrent audit: auditors are member of the system development team(2) Postimplementation audit: auditors seek to help an organization learn from its

experiences in the development of a specific application system(3) General audit: auditors evaluate systems development controls overall.(external audit 이

주로 시행 )

(2) Normative models of the system development process

SDLC Approach

(1) Feasibility study

(2) Information analysis

(3) System design

(4) Program development

(5) Procedure &forms development

(6) Acceptance testing

(7) conversion

(8) Operation & Maintenance

requirement

Cost-benefit


Sociotechnical Design Approach

Social

System

Technical

System

Sociotechnical design

High quality ofWorking life

High taskaccomplishment

Joint optimization

interaction

Diagnosis &

entry

Social System Design

Adjustment of coordinating mechanisms

Task systems design

Implementation

ManagementOf the changeprocess


Political Approach

Historical Analysis to determine power

structure

User

Participation

Face-to-face negotiation and

compromise

Will

Proposed system

Change power

Structure?

Start

ContinueContinue

YesNo


Soft-Systems Approach

Recognize the Problem situation

Express the Problem situation

Produce rootDefinitions of

Relevant systems

Develop conceptualModels of

Relevant systems

CompareConceptual models

With problem situation

IdentifyDesirable

And feasiblechanges

Take action toImprovesituation


Prototyping Approach

Elicit user requirement

Design

Prototype

Implement

Prototype

Use

Prototype

Build

Production

System


Information Engineering Approach

1. Information strategic planning

2. Business Area modeling

3. Business System Design

4. Technical Design

5. Construction

6. Transition

7. Production

- 전략정보계획에서부터 출발- 분석 / 설계 중심- 전략정보계획에서부터 출발- 분석 / 설계 중심


Contingency Approach

(1) Social system impact: impact 가 크면 behavior issue( 직무의 재설계 등에 사용자의 참여 등 ) 들을 고려하고 그렇지 않을 경우 중요하지 않음 .

(2) Task systems impact: 시스템이 직무의 수행이나 효과 , 효율성에 중심역할을 한다면 전문적인 개발인력이 참여하고 효과적인 커뮤니케이션과 높은 품질의 개발이 이루어져야 하고 , 그렇지 않을 경우는 최종사용자에 의해 개발될 수 있음 .

(3) System size: 대형시스템일경우 전문적인 개발인력이 참여하고 효과적인 컴뮤니케이션과 높은 품질의 개발이 이루어져야 하고 , 그렇지 않을 경우는 최종사용자에 의해 개발될 수 있음 .

(4) Commonality: 시스템이 상대적으로 common 하고 요구사항이 잘 이해되고 있다면 패키지를 구입할 수 있음 . 시스템이 impact 가 작다면 사용자가 구입가능하고 , 그렇지 않을 경우 정보시스템 전문가가 구입에 역할을 담당함 .

(5) Requirements uncertainty: 요구사항이 분명치 않으면 프로토타이핑이 중요하고 , 요구사항이 잘 이해되면 프로토타이핑은 불필요함 .

(6) Technology uncertainty: 조직의 경험이 부족한 기술을 사용하여 개발한다면 개발의 주요역할은 정보시스템 전문가에 의해 수행되어야 함 .

(1) Social system impact: impact 가 크면 behavior issue( 직무의 재설계 등에 사용자의 참여 등 ) 들을 고려하고 그렇지 않을 경우 중요하지 않음 .

(2) Task systems impact: 시스템이 직무의 수행이나 효과 , 효율성에 중심역할을 한다면 전문적인 개발인력이 참여하고 효과적인 커뮤니케이션과 높은 품질의 개발이 이루어져야 하고 , 그렇지 않을 경우는 최종사용자에 의해 개발될 수 있음 .

(3) System size: 대형시스템일경우 전문적인 개발인력이 참여하고 효과적인 컴뮤니케이션과 높은 품질의 개발이 이루어져야 하고 , 그렇지 않을 경우는 최종사용자에 의해 개발될 수 있음 .

(4) Commonality: 시스템이 상대적으로 common 하고 요구사항이 잘 이해되고 있다면 패키지를 구입할 수 있음 . 시스템이 impact 가 작다면 사용자가 구입가능하고 , 그렇지 않을 경우 정보시스템 전문가가 구입에 역할을 담당함 .

(5) Requirements uncertainty: 요구사항이 분명치 않으면 프로토타이핑이 중요하고 , 요구사항이 잘 이해되면 프로토타이핑은 불필요함 .

(6) Technology uncertainty: 조직의 경험이 부족한 기술을 사용하여 개발한다면 개발의 주요역할은 정보시스템 전문가에 의해 수행되어야 함 .

(3) Evaluating the major phases in systems development process

(1) Problem/opportunity definition(2) Management of the change process(3) Entry and feasibility assessment(4) Analysis of the existing system(5) Formulation of strategic requirements(6) Organizational and job design(7) Information processing system design(8) Application software acquisition and development(9) HW/SW acquisition(10) Procedure development(11) Acceptance testing(12) Conversion(13) Operation and maintenance

(1) Problem/opportunity definition(2) Management of the change process(3) Entry and feasibility assessment(4) Analysis of the existing system(5) Formulation of strategic requirements(6) Organizational and job design(7) Information processing system design(8) Application software acquisition and development(9) HW/SW acquisition(10) Procedure development(11) Acceptance testing(12) Conversion(13) Operation and maintenance


(1) 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?

(2) 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 ?

(3) 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?

(4) 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!

(1) 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?

(2) 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 ?

(3) 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?

(4) 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!

(1) Problem/opportunity definition


(2) Management of the change process

Planning

Analysis

Design

Construction

Implementation

Project Management

Change facilitation-unfreezing the organization-moving the organization-refreezing the organization

Evaluate quality of decision !

Auditor 의 관심 : 프로젝트 관리와 변화 과정을 위한 결정의 질을 평가Auditor 의 관심 : 프로젝트 관리와 변화 과정을 위한 결정의 질을 평가


(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 이 얼마나 성공적이었는지 평가

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

Operational

Economic

Behavioral

System development process

Is the available technology sufficient to support the proposed Project?Can the input data be collected for

The system? Output usable?

DO the benefits of the system exceed the costs?What impact ‘ll the system have on

The users’ QWL?


(4) Analysis of the existing system

(1) history, structure & culture: study 를 했는가 ? 필요한 면이 무엇인가 ? 어느정도 했는가 ?(2) Product & information flow: 조사의 범위와 근원 ?, 사용한 방법론 ? CASE Tool 의 사용 ?(1) history, structure & culture: study 를 했는가 ? 필요한 면이 무엇인가 ? 어느정도 했는가 ?(2) Product & information flow: 조사의 범위와 근원 ?, 사용한 방법론 ? CASE Tool 의 사용 ?

NEW SYSTEM

OLD SYSTEM

ExistingHistory, culture& structure

ExistingProduct & information flow

* 분석방법- Structured Analysis- OO Analysis- SSM

(5) Formulating strategic requirements

(1) strategic requirements: the overall goals and objectives the system must accomplish(2) Auditor: 시스템 설계자가 연속되는 설계작업의 품질을 위해 전략적인 요구사항들을

파악하는 중요성을 이해하고 있는지 파악

(1) strategic requirements: the overall goals and objectives the system must accomplish(2) Auditor: 시스템 설계자가 연속되는 설계작업의 품질을 위해 전략적인 요구사항들을

파악하는 중요성을 이해하고 있는지 파악


(6) Organizational & Job Design

(1) strategic requirements 의 만족을 위해 Organizational & Job redesign 필요(2) Auditor- 제안된 시스템이 조직의 구조나 직무에 영향을 줄 경우 시스템 개발팀이 조직의 역사나

실행에 숙련된 전문가로부터 고품질의 어드바이스를 받는지 파악- 조직의 구조나 직무설계를 책임지는 인력들이 각 담당자 그룹의 대표를 포함하는지 ,

설계작업이 어떻게 이행되고 있는지 , 갈등이나 불확실성들을 어떻게 해결하는지 , 최종적으로 선택되는 설계에 관련된 결론의 레벨이 어느 정도인지를 파악함 .

(1) strategic requirements 의 만족을 위해 Organizational & Job redesign 필요(2) Auditor- 제안된 시스템이 조직의 구조나 직무에 영향을 줄 경우 시스템 개발팀이 조직의 역사나

실행에 숙련된 전문가로부터 고품질의 어드바이스를 받는지 파악- 조직의 구조나 직무설계를 책임지는 인력들이 각 담당자 그룹의 대표를 포함하는지 ,

설계작업이 어떻게 이행되고 있는지 , 갈등이나 불확실성들을 어떻게 해결하는지 , 최종적으로 선택되는 설계에 관련된 결론의 레벨이 어느 정도인지를 파악함 .

(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

(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


UIDesign

platformDesign

SW

Requirementelicitation

Data/informationFlow design

PhysicalDesign

DBDesign

(8) Application software acquisition& development

(1) 구입시- 벤더에게 제공되는 요구 스펙의 충분성- 소프트웨어 평가 절차의 품질 ( 소프트웨어의 품질 , 벤더 유지보수 및 지원의 충분성 )(2) 개발시- 설계 , 코딩 , 컴파일링 , 테스팅 , 문서화 단계 동안 수행되는 절차의 평가

(1) 구입시- 벤더에게 제공되는 요구 스펙의 충분성- 소프트웨어 평가 절차의 품질 ( 소프트웨어의 품질 , 벤더 유지보수 및 지원의 충분성 )(2) 개발시- 설계 , 코딩 , 컴파일링 , 테스팅 , 문서화 단계 동안 수행되는 절차의 평가


RFPAdequacy of requirement spec?

Client Vendor

ProposalCompliance with requirements?Quality of documentation?Vendor stability & support?Nature of contractual obligations?

(9) HW/ System SW Acquisition

(1) Auditor- 벤더에게 제공되는 요구 스펙의 충분성 (RFP)- 평가 절차의 품질 - 벤더의 viability, ongoing support, the availabilty of source code & maintenance support

등의 파악

(1) Auditor- 벤더에게 제공되는 요구 스펙의 충분성 (RFP)- 평가 절차의 품질 - 벤더의 viability, ongoing support, the availabilty of source code & maintenance support

등의 파악


(10) Procedures Development

(1) 이 단계에서 설계자는 사용자가 시스템의 계속적인 운영과 유용한 산출물을 얻기 위해 수행해야 할 activity 들을 정의해야 한다 .

(2) 절차개발- Design of procedures- Testing of procedures- Implementation of procedures- Documentation of procedures(3) Auditor- 절차설계의 품질 평가 (minimum spec of procedures)- 시스템이 behavioral impact 를 가져올경우 절차 설계팀에 관련자 대표 포함- 절차를 테스트하는데 사용되는 접근법을 평가함 .- 절차 문서화의 품질을 평가함 .

(1) 이 단계에서 설계자는 사용자가 시스템의 계속적인 운영과 유용한 산출물을 얻기 위해 수행해야 할 activity 들을 정의해야 한다 .

(2) 절차개발- Design of procedures- Testing of procedures- Implementation of procedures- Documentation of procedures(3) Auditor- 절차설계의 품질 평가 (minimum spec of procedures)- 시스템이 behavioral impact 를 가져올경우 절차 설계팀에 관련자 대표 포함- 절차를 테스트하는데 사용되는 접근법을 평가함 .- 절차 문서화의 품질을 평가함 .

(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

(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

Program test

Program test

System TestQA Test

User Test

(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

(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

(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.

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.


(13) Operation & Maintenance(Source Library control)


System Development

Test library

System Maintenance

Test library

Applicationprogram

Applicationprogram

SPL

Applicationprogram

Compile &Link edit

ApplicationLoad module

Production

SystemsDevelopmentprogrammers

Systemsmaintenanceprogrammers

Maintenancerequest

ProgramListing

ProgramChangereport

Documentationfile

users

SPL ManagementSystem

- 프로그램 저장- 유지보수를 위해프로그램 추출- 라이브라리에서프로그램제거- 프로그램변경 문서화

Documents

Information Systems Control & Audit(3) Shin, SooJung Based on Ron’s book