[Domain 3] 정보시스템 구입, 개발 및 구현 (SDLC) (요약)

※ CISA 시험 공부하면서 요약 정리한 것으로 일부 중복된 내용 또는 오류가 있을 수 있습니다.

---

1. 프로젝트 지배

■ 의의

• 프로젝트가 조직 및 IT의 전략적 목적 달성을 보증한다.

■ 사업 사례 (Business Case)

• 초기 버전은 타당성 조사 단계에서 작성되고, 검토되며, 승인된다.
• 제시된 기대 이익은 현실적이어야 한다.
• 주요한 시점마다 재검토하고 (필요 시) 변경하고 재승인해야 한다.
• 사업 사례는 이사회 및 고위 경영진의 승인을 받아야 한다.

■ 프로젝트 관리 사무국 (Project Management Office)

• 조직 내 프로젝트들을 통합 관리한다.

■ 프로젝트 포트폴리오 관리 (Project Portfolio Management)

• (1) 프로젝트 포트폴리오 DB & (2) 프로젝트 포트폴리오 보고서
• ROI (Return on Investment) : 투자 대비 효익을 계산해 주며, 계산이 용이하며, 널리 사용된다.
• 순현재가치 (NPV : Net Present Value) : 사업의 가치를 나타내는 척도 중 하나로 최초 투자 시기부터 사업이 끝나는 시기까지의 연도별 순편익의 흐름을 각각 현재 가치로 환산한 것 - 가장 우수한 기법 (순현재 가치(편익의 현재가치 - 비용의 현재 가치 = 순현재 가치)가 0보다 크면 일단 그 사업은 채택 가능한 것으로 판단)

■ 사업 효익 실현 기법

• 사업 사례와 단계 말 평가 (gateway assessment)
• 구현 후 검토 (Post implementation review)

■ 프로젝트 운영 위원회

• 프로젝트 진행 현황을 검토하고, 필요 시 긴급회의를 연다.
• 전사적 프로젝트인 경우, 위원장은 임원급 경영진이 바람직하다.
• 필요한 교정 조치를 취하거나 권고한다.
• 때때로 프로젝트 중단을 결정하기도 한다.

2. 프로젝트 관리

■ 삼중 제약 (Triple Constraints)

• 산출물 (Deliverables) → 범위 (Scope) 관리
• 시간/기간 (Time/Duration) → 시간 (Time) 관리
• 비용/자원 (Cost/Resources) → 원가 (Cost) 관리

■ 프로젝트 관리 프로세스

• 개시 (Initiation)
  • 프로젝트 관리자나 후원자가 매 단계를 개시한다.
  • Terms of reference (합의서) 또는 Project charter (프로젝트 헌장)을 작성하는 일로부터 시작한다.
  • PID (Project Initiation Document), PRD (Project Request Document)에 대해 승인하면 개시 권한이 위힘된다. (PID : 프로젝트 개시 문서, PRD : 프로젝트 요청 문서)
• 기획 (Planning)
  • 프로젝트 관리자는 (프로젝트 팀원들과 함께) (1) 수행 활동의 범위 (2) 일정 (3) 예산 및 자금 조달 원천 등을 결정해야 한다.
• 실행 (Implementation)
  • 자원 소모가 가장 많은 프로세스이다.
  • 계획된 활동들을 수행하여 산출물 및 인도물을 완성한다.
  • 프로젝트 실행 과정을 관리하고 문서화한다.
• 통제 (Controlling)
  • 범위, 시간, 원가 및 위험 관리 상의 변경을 통제한다.
  • 새로운 변경 요청이 승인되면, 문서화하고 자원을 할당한다.
• 종료 (Closing)
  • 시스템을 사용자 및 지원 직원들에게 넘겨준다.
  • 각종 성과를 측정하고, 교훈점을 문서화한다.

3. 프로젝트 범위 관리

■ 프로젝트 목적

• 목적 요건 → SMART
  • Specific (구체적)
  • Measurable (측정 가능한)
  • Achievable (달성 가능한) : 목적은 현실적 즉 실현 가능해야 한다.
  • Relevant (관련된)
  • Time-bound (기한이 있는)
• 목적의 유형
  • 주요 목적 (Main Objective)
  • 추가 목표 (Additional Objective)
  • 비 목표 (Non-Objective)

■ 범위 관리 도구

• 객체 분류 체계 (OBS : Object Breakdown Structure)
  • 산출물 지향적이다.
  • 프로젝트 목적 달성을 위한 솔루션 (Solution)을 정의한다.
  • 솔루션의 구성요소들을 계층 구조로 분할한다.
• 업무 분류 체계 (WBS : Work Breakdown Structure)
  • 활동 지향적이다.
  • OBS의 구성요소들을 완성하는 데 필요한 활동들을 정의한다.
  • 비용 및 자원 기획을 위한 기준선(baseline)이다.
  • 최하위 활동 단위는 작업 패키지 (work package)이다.
    • 주요 목표의 목록과 소유자가 포함되어야 한다.
    • 부가적 목표 및 비 목표 목록을 포함할 수도 있다.
    • 해야 할 일(To-Do) 목록이 자주 사용된다.

4. 프로젝트 시간 관리

■ Gantt Chart (= Bar Chart)

• 활동 간 상호 관계 파일이 용이하지 않다.
• 팀원들이 프로젝트 일정 및 목표 달성 여부 검토에 유용하다.

■ 네트워크 다이어그래밍 기법

• (1) 활동 목록 (2) 순서 및 상호 관계 (3) 소요 시간 산정이 끝나야 네트워크 다이어그램을 그릴 수 있다.
• 크리티컬 패스 분석법 (CPM : Critical Path Methodology) : 프로젝트를 완료하는 데 필요한 작업을 식별하고 일정의 유연성을 판단하는 기술
  • 유사한 프로젝트 경험이 어느 정도 있는 경우 적합하다.
  • 핵심 경로 (Critical Path) : 순방향 일정 수립으로 계산
    • 여유시간이 전혀 없는 일련의 연속적인 작업
    • 가장 긴 경로 및 프로젝트 완료에 필요한 최소한의 기간
    • 일정 관리를 위한 핵심 활동들이다.
  • 여유 시간 (Slack time, Total fload) : 역방향 일정 수립으로 계산
    • 핵심 경로의 여유 시간은 일반적으로 0이다.
  • 충돌 (Crashing) : 핵심 경로(CP : Critical Path)에 자원을 추가하여 일정을 단축한다.
  • 리소스 평준화 (Resource Leveling) : (일정 단축은 하지 않지만) 희소 자원이 특정 기간에 집중 사용되지 않도록 사용 기간을 분산시킨다.
• PERT (Program Evaluation Review Technique) - 프로젝트 평가 검토 기법
  • 규모가 크고 복잡한 프로젝트를 보다 수월하게 계획할 수 있도록 설계된 프로젝트 관리 체계로 프로젝트에 대한 전반적인 평가로 시작하는 이 기법은 프로젝트를 개시하기 전에 프로젝트에 대한 심층적인 분석을 가능하게 함
  • 베타 분포를 사용하며, 위험을 고려한다.
  • **최빈값 (Most likely)**으로 태스크 수행 기간을 산정한다.

■ Time-Box 관리

• 작업 활동을 위한 엄격한 시간대를 규정한다.
• RAD (Rapid Application Development)나 EU (End User Computing) 등에서 활용된다.
• 프로토타이핑 기법을 사용할 때 일정 지연이 예상된다면, 핵심 기능들만 타임 박스 기법을 적용하여 개발하는 것이 바람직하다.

5. 프로젝트 원가 관리

■ 원시 코드의 라인 수 (SLOC : Source Line of Code)

• 프로그램에 포함되는 명령어의 라인 수로 측정한다.
• KLOC : 1,000 라인 단위로 측정

■ 기능 점수 분석 (FPA : Functional Point Analysis)

• 대규모 응용 시스템을 개발할 때 규모 및 원가를 산정하는 데 널리 사용되는 방법이다.
• 하향식 방법이다.
• 가장 객관적이고 합리적인 방법이다.

■ FPA Feature Points

• FPA 기법을 웹 응용에 적용시킨 것이다.

■ 기타 기법

• 전문가 판단
  • 전무가의 경험에 근거한다.
• Delphi 기법
  • 전문가 판단의 일종이다.
  • 여러 전무가들에게 서신으로 의견을 문의하여 취합한다.
• 상향식 산정 (Bottom-up) 기법
  • 업무 분류 체계 (WBS : Work Breakdown Structure)를 활용한다.
  • 작업 패키지 수준에서 단가를 계산한 후 집계한다.
• 회귀 분석 (Regression) 기법
  • 장기간에 걸쳐 수집한 과거의 실적 데이터를 사용하여 관련 변수들과 원가 간의 함수 관계를 분석한다.

6. 응용 개발 관련자

집단 및 개인	역할
고위 경영진	- 비용/인력, 프로젝트 개시 등 승인  - 프로젝트 완수를 위한 자원 확보
프로젝트 후원자	- 비용 제공  - 프로젝트 중 데이터와 응용의 소유자  - 프로젝트 관리자와 협조하여 성공 측정
프로젝트 운영 위원회	- 전사적 프로젝트인 경우 의장은 임원급  - 이해 관계자들의 대표자들로 구성  - 작업 진행의 정기적인 검토, 조정 및 선언  - 프로젝트의 진행 상활을 사용자에게 보고
프로젝트 관리자	- 관련 부서의 의견 조정, 산출물 품질 유지, 일정 관리
시스템 개발 관리진	- 기존 전산 환경과 호환성 제공  - 기술적 지원  - 시스템의 기업의 전략적 추진 방향과 일관성을 유지하게 함
시스템 개발 프로젝트 팀	- 세부 기준 따라 사용자와 협의하여 작업 수행
사용자 관리진	- 요구사항 정의  - 시스템 테스트 및 사용자 교육 참여  - 프로젝트와 최종 시스템의 소유자
사용자 프로젝트 팀	- 세부 기준 따라 개발팀과 협의하여 작업 수행
보안 관리자	- 시스템 설계가 기업의 보안 정책과 일치하는지 검토  - 시스템에 포함시켜야 할 보안대책 상담
품질 관리자	- 각 단계의 작업 결과 및 산출물 검토  - 최종 단계에서는 요구사항 준거성 검토

7. 업무 응용 개발 방법론

■ 주요 수명 주기 모델

• 폭포수 (Waterfall) 모형
• 프로토타이핑(Prototyping) 모형
  • 시스템의 주요 기능을 초기에 개발하고 이를 발전시킨다.
• 나선형 (Spiral) 모형 : 프로토타이핑 모형 + 위험 관리 프로세스
• 반복형 (Iterative) 모형 : 모든 모형을 결합한 것이다.

■ 개발 생산성 향상 접근법

• 구조적 개발 (Structured Development)
  • 모듈 단위 개발을 통해 **유지 보수성 (maintainability)**을 높인다.
• 객체 지향 개발 (Object Oriented Decelopment)
  • Object : 모듈에 데이터를 포함시킨 개념이다.
  • 클래스 (Class), 상속 (inheritance), 캡슐화 (encapsulation)
  • 캡슐화 및 정보 은익은 보안을 향상한다.
  • **소스 코드의 재사용성 (reusability)**을 제공한다.
  • 복잡한 시스템 구축을 용이하게 한다.
• 컴포넌트 기반 개발 (CBD : Component Based Development)
  • 인터페이스를 표준화하여 컴포넌트들을 연계시킨다.
  • **목적 코드의 재사용성 (reusability)**을 제공한다.
• 웹 기반 응용 개발 (Web-based Application Development)
  • 이질적 환경에서 개발된 시스템들을 통합한다.
  • WSDL (Web Service Description Language) : 웹 서비스 기술언어 또는 기술된 정의 파일의 총칭으로 XML로 기술 → 웹 서비스 등록
  • UDDI (Universal Description, Discovery and Integration) : 웹 서비스 관련 정보의 공개와 탐색을 위한 표준 → 웹 서비스 검색을 지원한다.
  • SOAP (Simple Object Access Protocol) : 일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜. SOAP은 웹 서비스에서 기본적인 메시지를 전달하는 기반이 됨 → 웹 서비스의 원격 호출 과정에 사용되며 주소의 무결성을 향상한다.

■ 다양한 개발 접근법

• RAD (Rapid Application Development) - 고속 응용 프로그램 개발
  • 전략적으로 중요한 시스템을 신속하고 저렴하면서도 좋은 품질로 개발하는 방법
  • 주요 관리 기법
    • SWAT (Small and Well Advanced Team)
    • 진화적 프로토다이핑
    • 효과적인 CASE 도구의 이용
    • 중앙 리파지토리
    • JAD (Joint Application Design - 결합 응용 설계) : 사용자와 개발자가 함께 설계를 진행한다.
    • Time-boxing 기법
• 민첩 개발 (Agile Development)
  • 장기적인 계획 없이 바로 다음 단계만을 계획하고 개발하는 상황 적응적인 개발 사상
  • 불확실하고 가변적인 사용자 요구사항 적응에 적합하다.
  • 대형 프로젝트에 적용하기에는 적합하지 않다.
• 역공학 (Reverse-engineering)
  • 개발 산출물에서 설계 산출물 또는 설계 산출물에서 분석 산출물을 체계적으로 도출하는 접근법이다.
  • De-compiler : 목적 코드에서 소스 코드를 생성한다.
  • Black-box testing : 디컴파일러가 없을 때 사용할 수 있다.
  • 역공학 금지 조항이 있는지 확인해야 한다.
• 재공학 (Re-engineering)
  • 역공학을 통해 분석/설계 산출물을 확보한 후, 순공학을 통해 시스템을 개선시킨다.

8. 시스템 개발 및 감사

9. 타당성 검토

■ 주요 수행 활동

• 시스템 개발/구입의 효과, 비용 및 위험을 평가한다.
  • 기술적, 경제적, 법적 타당성을 검토한다.
  • 투자수익률 (ROI : Return on Investment) 및 순현재가치 (NPV : Net Present Value) 등을 추정하고 평가한다. → IT 투자 예산 편성을 위한 의사결정의 지표가 된다.
  • 초기 사업 사례를 수립하고, 고위 경영진의 승인을 받는다.
• 경영 필요, 목표 및 전략과 솔루션의 일치성을 평가한다.
• 시스템 개발 및 변경 요청은 누구나 할 수 있지만, 그 타당성 및 우선순위의 결정은 IS 운영위원회에서 결정한다.
• 시스템을 개발할 것인지 아니면 구입할 것인지를 결정한다.

■ 중점 감사 항목

• 초기 사업 사례가 고위 경영진의 승인을 받았는지 검토한다.
• 타당성 조사 문서가 합리적인지 검토한다.
• 비용이 타당하며, 효과가 검증 및 실현 가능한지를 판단한다.
• 필요 (Needs)의 중요도를 식별한다.
• 필요 및 문자게 기존 시스템으로도 해결 가능한지 여부를 판단한다.
• 선택된 솔루션 방향 (개발 또는 구입)의 적합성을 판단한다.

10. 요구사항 정의 (= 개념적 설계)

■ 주요 수행 활동

• 이해관계자들을 식별하고 기대사항을 파악한다.
• 사용자 요구사항을 시스템 요구사항으로 변환한다.
  • 대화형 사용자 인터페이스의 프로토타입을 만들어 보여준다.
• 요구사항의 완전성 및 일관성을 검증한다.
• 개념적 프로세스 모형과 개념적 데이터 모형을 만든다.
• 정보 및 데이터 요구사항 정의를 위하여 ERD를 작성한다.
  • 객체-관계 모델 (ERD : Entity Relationship Diagram) : 데이터 객체와 데이터 객체 간 관계를 도식화한다.
• Cf. 프로세스 모델링 도구로 DFD (Data Flow Diagram)을 작성하기도 한다.
• 사용자 인수 테스트 사양서를 작성한다.

■ 중점 감사 항목

• 요구사항의 정확성을 검증한다.
• 관련 있는 모든 사용자 집단이 적절히 포함되었는지 검증한다.
• 프로젝트 착수 및 비용에 대한 적합한 경영진 승인이 있었는지 검증한다.
• 개념적 설계 사양서를 검토하여 사용자 필요를 다루는지 확인한다.
  • 통제 사양이 정의되었는지 확인한다.
• 사용자 인수 테스트 (UAT) 사양서를 검토한다.
  • 인수 테스트 요구사항은 요구사항 정의 단계에서 도출한다.
• **내부 감사 모듈 (EAM)**이 필요한지 검토하고, 필요하다면 개념 설계에 포함시킨다.

11. 구입

■ 주요 수행 활동

• 정보 요청서 (RFI : Request for Information) 발송
  • 업체들로부터 문제 해결 방법에 대하여 자문을 받는다.
  • 제안요청서 (RFP : Request for Proposal)를 작성하기 위한 정보를 수집한다.
• 제안 요청서 (RFP : Request for Proposal) 발송 및 제안 설명회
  • 지원 및 유지보수가 중요할 경우 이를 강조한다.
  • 정직한 제안서 작성을 위한 동기 부여를 위해, 제안서 내용이 계약서에 반영될 것임을 명시한다.
  • 가격 및 서비스가 강조될 경우에는 입찰요청 (ITT : Invitation to Tender)를 작성한다. → 입찰초대 (ITT : Invitation to Tender) : 여러 공급자 또는 계약자로부터 경쟁 제안을 생성하기 위한 공식적이고 구조화된 절차
• 제안서 (Proposal) 접수, 평가 및 제품 선정
  • 제안서 제출 업체들 중에서, 1차 선별된 소수의 후보 업체들을 포함한 Short list를 작성할 수도 있다.
  • 최종 업체 선정을 위한 상세한 비용-효익 분석을 한다.
• 계약
  • 제품 선정 이후에는 유리한 계약 조건을 이끌어 내기 위한 협상 절차가 중요하다.
• 구성 (Configutation)
  • 시스템 통제 파라미터를 요구사항에 맞게 설정한다.
  • 인증 (Certification) 및 인가 (Accreditation) 과정을 거친다.

■ 중점 감사 항목

• 보안 통제 (감사 증적, 패스워드 통제, 기타 전반적 보안 등)의 적합성을 검토한다.
• 제안요청서 (RFP : Request for Proposal)가 적합한지 그리고 제안서가 제안요청서 (RFP : Request for Proposal)에 부합되는지 판단한다.
• 계약 체결 전에 법률 담당 부서에서 검토하였는지 확인한다.
• 패키지는 자체 개발에 비해 유연성은 높으나 처리 효율성은 낫다.

12. 상세 설계

■ 주요 수행 활동

• 시스템을 모듈 및 컴포넌트로 분할한다.
• (물리적 수준의) 시스템 흐름도 및 객체-관계 모델 (ERD : Entity Relationship Diagram)를 작성한다.
• (프로토타이필 도구를 사용하여) 화면 설계 및 보고서와 같은 입출력을 기술한다.
• 처리 단계 및 계산 규칙을 결정한다.
• 다양한 요구사항 및 정보 기준을 위한 프로그램 사양서를 작성한다.
• 다양한 테스트 계획을 개발한다. : 단위, 통합 및 시스템 테스트 등
• 데이터 변환 계획을 개발한다 : 실제 변환은 구현 단계에서 한다.
• (요구사항/변경/버전/형상 관리를 위한) 설계 단계의 절리 (cutoff) 또는 동결 (freezing) 시점으로 기준선 (baseline)을 설정한다. → 기준선 (baseline)은 **범위 변경 (scope creep)**을 통제하기 귀한 변경 통제 및 형상 관리의 기준이 된다.
• 기준선 (baseline) 설정 후 사양서를 담당 프로그래머들에게 배포한다.

■ 중점 감사 항목

• 시스템 사양서 및 테스트 계획을 검토하여 (입력/처리/출력 통제 등을 포함하여) 적절한 통제 시스템이 포함되어 있는지 살핀다.
  • 개념 설계 때 도출된 통제 사양이 시스템 사양서에 반영되었는지 확인 및 검증해야 한다.
  • 지속적 감사 기능이 시스템 사양서에 내장되었는지 판단한다.
• 사용자 인터페이스 설계 시 사용자 참여를 검증한다.
• 변경 통제 절차서를 검토하고, 모든 번경 사항에 대한 승인이 있었는지 검증한다.
• 설계 과정의 효과성을 평가한다.
  • 구조적 설계 기법, 프로토타이핑, 테스트 계획 및 기준선 (baseline) 설정 등의 효과성을 검토한다.

13. 개발 (=프로그래밍)

■ 주요 수행 활동

• 프로그램 코딩 표준 적용 - 필드명명 규칙
• 코딩 및 디버깅을 수행한다.

컴파일러는 디버깅 도구가 아니다!!!

• 단위 테스트를 수행한다.
• 데이터 변환 프로그램을 작성한다.
• 사용자가 새로운 시스템으로 전환 (transition) 하기 위한 절차를 개발한다.
• 핵심 사용자들을 선정하여 시스템 사용법을 교육한다.
• 벤더로부터 구입한 소프트웨어에 대한 변경 및 문서화가 정확하고 완전하게 이루어졌는지를 확인한다.

■ 중점 감사 항목

• 회계성 (Accountability) 및 추적 가능성을 확보하기 위한 감사 증적의 적합성을 평가한다.
• 중요한 처리 및 계산의 무결성을 검증한다.
• 시스템 오류의 식별과 처리가 적절하였는지 검토한다.
• 개발된 프로그램에 대한 독립적 품질 보증 결과를 검토한다.
• 프로그래밍 오류에 대한 교정조치가 수행되었는지 검증한다.
• 감사 증적 및 내장 감사 모듈이 작성되었는지 검증한다.

14. 테스트

■ 주요 수행 활동

• 초기에 개발되어 정련되어 오던 테스트 계획을 확정한다.
• 대규모 시스템은 주로 상향식 테스트를 수행한다.
  • 상향식 테스트
    • 단위 테스트 → 연계/통합 테스트 → 시스템 테스트
    • 스터브와 드라이버가 필요 없다.
    • 핵심 모듈의 오류를 일찍 발견할 수 있다.
  • 하향식 테스트
    • 시스템 테스트 → 연계/통합 테스트 → 단위 테스트
    • 주요 기능 및 처리에 대한 테스트를 조기에 수행한다.
    • 인터페이스 오류를 좀 더 일찍 발견할 수 있다.
• 데이터 변화 프로그램을 작성한다.
• 참고 : 테스트 유형
  • 알파 (내부) vs 베타 (외부) 테스트 → 사용자 참여
  • 화이트 박스 vs 블랙박스 테스트
  • 회귀 (regression) 테스트 : 변경으로 인한 새로운 오류가 발생하였는지 검증한다.
  • 병행 (Parallel) 테스트 : 변경된 시스템의 무결성 검증에 가장 효과적인 방법이다. → 자주 출제된다.!!!! ★★★★★
  • 사회성 (Sociability) 테스트 : 새로 설치된 프로그램이 기존의 시스템에 나쁜 영향을 주지 않는지 검증한다.

■ 중점 감사 항목

• 테스트 계획의 완전성을 검토한다.
• 테스트 시나리오 개발 과정에서의 사용자 참여를 검토한다.
• 테스트 과정, 결과 및 이의 문서화가 적절한지 검토한다.
• 오류 보고서를 검토하고 적절히 해경 되었는지 검토한다.

15. 구현

■ 주요 수행 활동

• 실제 운영 환경을 구현하고 테스트한다.
• 운영 및 콜 센터의 구축 및 운영 계획을 수립하고 교육을 수행한다.
• (1) 사용자 매뉴얼 (2) 운영자 매뉴얼 등을 완성한다.
• **데이터 변환 (Data conversion)**을 수행한다.
• 이관 (Magration) 계획 정련 및 복귀 (fallback) 시나리오 개발을 한다.
• 품질 보증 테스트 (QAT : Quality assurance testing)와 사용자 인수 테스트 (UAT : User Acceptance Testing)를 수행한다.
• 인증 (Certification)과 인가 (Accreditation)을 수행한다.
  • 인증 : 표준, 정책 및 절차 등의 준거성을 조사한다.
  • 인가 : 인증 기관이 인증서 (certificate)를 고객에게 발부한다.
• IS 감사인의 시스템 평가 보고서를 경영진에게 제출한다.
• 응용 프로그램은 운영 직원이 소스코드를 프로덕션 라이브러리로 복사해 온 후, 컴파일되어야 한다.
  • 가장 바람직한 순서는 (1) 라이브러리 안 (2) 변경 관리자 (3) 품질 보증 (4) 보안 관리자 (5) DBA (6) 운영자 순이다.
• 시스템을 대체 (cutover, changever)를 수행한다.
  • 급격한 (Abrupt) 대체 : 빅뱅 방식으로 일시에 전체를 대체한다.
  • 단계적 (Phased) 대체 : 증분적 또는 파일롯 방식이다.
  • 병행적 (Phased) 대체 : 기존 시스템과 신규 (또는 변경) 시스템을 일시적으로 병행 사용한다. 상기 두 가지 방법들 중 하나와 결합하여 사용된다 → 시나리오로 자주 출제됨!!!! ★★★★★

■ 중점 감사 항목

• 구현 전 사용자 인수 테스트가 있었는지 검증한다.
• 사용자 인수 테스트 결과 및 오류 보고서를 검토한다.
• 인수 테스트가 끝난 패키지가 타 버전으로 대체되었는지 검토한다.
• 시스템 파라미터 설정의 적절성, 모든 문서화의 완전성을 검토한다.
• 데이터 변환 결과를 검증한다.

16. 구현 후 검토

■ 주요 수행 활동

• 구현 후 6 ~ 18개월 후에 수행한다.
• 업무 (Business)에 실현된 가치를 평가하고 목적 달성을 측정한다.
• (1) 개발 조직과 최종 사용자가 수행하거나 (2) 독립적인 감사인이 수행할 수 있다.
  • 독립적 감사인 위주로 수행할 경우 통제에 초점을 맞춘다.
• 시스템의 적합성을 평가한다.
  • 사용자 요구사항 및 경영진의 목적을 충족하는가?
  • 접근 통제가 적절히 정의되고 구현되었는가?
• 예상했던 비용 대비 효과 및 투자수익률 (ROI : Return on Investment)가 실제로 달성되었는지 평가한다.
• 시스템 부적합성 및 약점을 다루기 위한 권고안을 개발한다.
• 권고안 구현을 위한 계획을 개발한다.
• 개발 프로젝트 프로세스를 평가한다.
  • 선정된 방법론, 포준 및 기법을 준수되었는가?
  • 적정한 프로젝트 관리 기법이 사용되었는가?

■ 중점 감사 항목

• 시스템 목적 및 요구사항이 달성되었는지 판단한다.
• 타당성 조사 단계에서 정의된 비용 대비 효과가 측정, 분석되어, 경영진에게 정확하게 보고되었는지 판단한다.
• 변경 요청의 유형을 검토하여, 설계/ 프로그래밍 / 사용자 요구사항의 해석 과정에서 문제가 있었는지 판단한다.
• 설치된 통제가 설계된 대로 작동하는지 검토한다.
  • 내부 감사 모듈 (EAM)이 설치되었다면 이 기능을 사용할 수 있다.
• 운영자 오류 로그를 검토하여 자원 및 운영 상의 문제가 있는지 판단한다.
• 입출력 잔액 및 보고서를 검토하여 데이터 처리 정확성을 검증한다.

17. 정보시스템 유지보수 실무

■ 형상 관리 (Configuration Management)

• 의의
  • 소프트웨어 제품 정보에 대한 완전한 이력의 유지
  • 버전 관리, 변경 관리 및 출시 (release) 관리 등을 포함한다.
  • 형상 (configuration)이란 제품의 구성요소 및 구성요소들의 특징을 가리킨다.
• 절차
  • 형상 식별 (identification)
  • 형상 통제
  • 형상 문서화 (기록)
  • 형상 감사

■ 변경 관리 (Change Management)

• 의의
  • 승인 없는 변경 방지
• 절차
  • 변경 요청 (request) 및 승인 (approval)
  • 변경 수행, 테스트 및 인수 (acceptance)
  • 문서 변경 및 이관

■ 비상 변경

• 특수 로그-온 ID를 알려주어 변경을 하게 하되 활동을 로깅한다.
• 활동 로그를 분석하고, 특수 로그-온 ID와 패스워드를 변경한다.
• 비상 변경에 대한 핵심 통제의 골자는 비상 변경을 위해 수행한 활동들에 대한 감시이다.
• 정상적인 변경 통제를 사후 적용한다.

18. 코드 비교 (Code Comparison) 절차

■ 샘플링

• 프로덕션 프로그램 목록을 확보하고, 최신성과 완전성을 검증한다.
• 표본의 크기를 결정하고 샘플링을 수행한다.

■ 변경 식별 → 매우 자주 출제된다.!!!

• 추출된 프로덕션 프로그램의 통제용 소스 코드를 확보한다.
  • (1) 해당 소스코드와 현행 프로덕션 프로그램의 생성 일자 및 시간이 일치하는지 비교한다.
• 통제용 소스코드를 다시 컴파일한다.
  • (2) 재 생성된 목적 코드와 프로덕션 코드의 길이를 비교한다.
  • (2) 코드 비교 소프트웨어를 사용하여 프로그램의 내용이 일치하는지 비교한다.

■ 승인 여부 검토 (준거성 테스트이다)

• 변경이 발생한 프로그램에 대하여 관련 문서를 역추적한다.
  • 사용자 인수 → 변경 테스트 → 변경 승인 → 변경 요청

■ 프로그램 변경 통제 (PCC) 절차의 효과성에 대한 판단

• 샘플 위반율 (SDR)을 계산한다.
  • SDT (Sample Deviation Rate) = 불법 변경 건수 / 표본 크기
• 모집단 위반율 (PDF)의 최대치를 추정한다.
  • PDR (Projected Deviation Rate) = SDR + Precision
  • Precision (정도) : 감사인이 결정한다.
• 프로그램 변경 통제 (PCC) 절차의 효과성에 대해 판단한다.
  • 모집단 위반율 (PDR)을 허용 편차율 (TDR : Tolerable Deviation Rat)과 비교한다.
  • PDR (Tolerable Deviation Rat : 모집단 위반율) < TDR (Tolerable Deviation Rat : 허용 편차율)이면 통제 위험을 낮게 평하한다. (통제 신뢰)
  • TDR (Tolerable Deviation Rat : 허용 편차율) < PDR (Tolerable Deviation Rat : 모집단 위반율) 이면 통제 위험을 높게 평하한다. (통제 불신)

19. 자동화 및 생산성 향상 도구

■ Computer Aided Software Engineering (CASE) 도구

• 상위 (Upper) CASE 도구
  • 기획 및 개념 설계 단계 지원
  • 각종 분석 다이어그램 작성 지원
• 중위 (Middle) CASE 도구
  • 상세 설계 단계 지원
  • 화면 및 보고서 양식 설계
  • 시스템 사양서 작성 지원
• 하위 (Lower) CASE 도구
  • 개발 단계 지원
  • 프로그램 코드 생성 및 데이터베이스 정의 (=스키마 생성)
  • 코드 생성기 (Code Generators)
    • 프로그래밍 언어로 쓰인 모듈화 된 코드 생성

■ 4세대 언어

• 프로그래머가 아닌 사람도 사용하기 쉽고 빨리 프로그래밍을 할 수 있는 프로그래밍 언어
• 비절차 언어
• 간이어

20. 업무 프로세스 재설계 (BPR : Business Process Re-engineering)

■ 업무 프로세스 재설계 (BPR) 기법- 벤치마킹 수행 절차

• 계획 : 벤치마킹 대상 프로세스 및 프로젝트 수행 계획 수립
• 연구 : 자기 조직을 분석하고 벤치마킹 대상 조직에 대한 기본 조사
• 관찰 : 벤치마킹 대상 조직 방문 및 데이터 수집
• 분석 : Gap 분석 및 목표 수립
• 적응 : 반영 원칙 수립 및 실행 전략/계획 수립
• 개선 : 지속적 개선

■ 업무 프로세스 재설계 (BPR)의 영향

• 업무 프로세스 재설계 (BPR)이 성공할 경우 극적인 성과 향상이 발생할 수 있다.
• 공급자 및 고객의 역할을 재정의하며 그들과의 관계를 개선한다.
• 업무 우선순위가 가치와 고객의 요구에 기초하여 식별된다.
• 업무 프로세스 재설계 (BPR)은 업무 분장 등 전통적인 예방 통제를 완화하는 경향이 있다.

■ 업무 프로세스 재설계 (BPR) 감사 중점 사항

• 제거되는 예방 통제를 식별하고 영향을 평가한다.
  • 예방 통제가 제거될 경우의 위험을 경고하고 위험을 감수할 의사가 있는지 확인한다.
  • 절감되는 통제 비용이 증가하는 위험 비용보다 작다는 점을 지적한다.
  • 사전 승인과 같은 예방 통제가 사라지는 경우, 감독자의 사후 검토와 같은 보완 통제가 구현되었는지 검토한다.
• 프로세스의 변경은 포르세스 소유자가 승인해야 한다.
• 변화 관리 절차를 평가한다.

21. 소프트웨어 품질 척도

■ ISO 9126의 (사용자 관점의) 품질 특성

• 기능성 (Functionality)
  • 요구한 모든 기능이 구현되었는가?
• 신뢰성 (Reliability)
  • S/W 기능이 안정적으로 작동되는가?
  • 처리의 일관성 및 기능의 연속성
  • 처리 실패 및 오류의 횟수로 측정될 수 있다.
  • 관련 지표 - MTBF (Mean Time Between Failures : 평균 고장 간격)
• 사용성 (Usability)
  • 사용법을 배우고, 사용하기 쉬운가?
  • 사용자와 친근한 인터페이스 설계 등이 관련된다.
• 효율성 (Efficiency)
  • 정보 처리에 소요된 시간과 자원이 경제적인가?
  • 관련 지표 - Throughput index (처리량 지수), response time (응답 시간)
  • 배치 환경에서는 response time (응답 시간) 대신 turnaround time (처리시간)을 사용한다.
• 이식성 (Protability)
  • 이질적 환경에서도 쉽게 설치되는가?
• 유지 보수성 (Maintainability)
  • 기능 추가와 변경이 용이한가?
  • 소프트웨어를 변경하는 데 소요되는 자원 및 시간으로 측정될 수 있다.
  • 하드웨어 관련 지표 - MTTR (Mean Time To Repair : 평균 수리 시간)

22. 소프트웨어 개발 향상 기법

■ IT 프로세스 향상을 위한 프로세스 성숙 평가 모형

• 미국의 CMM
• 유럽의 SPICE

■ CMM (Capability Maturity Model) - 능력 성숙도 모델

• Level1 (initial : 초기) - 즉흥적 대응 : 개인의 역량에 따라 프로젝트의 성공과 실패가 좌우되며, 소프트웨어 개발 프로세스는 거의 없는 상태를 의미
• Level2 (Repeatable : 반복) - 경험에 근거한 관리 : 프로세스 하에서 프로젝트가 통제되는 수준으로 조직은 프로세스에 대한 어느 정도의 훈련이 되었다고 볼 수는 있지만, 일정이나 비용과 같은 관리 프로세스 중심이며, 기존 유사 성공사례를 응용하여 반복적으로 사용
• Level3 (Defined : 정의) - 표준화되고 문서화된 프로세스 적용 : 세부 표준 프로세스가 있어 프로젝트가 통제됨
• Level4 (Managed : 관리) - 잘 문서화된 프로세스를 따르며 계량적 측정 수행
• Level5 (Optimizing : 최적화) - 지속적인 프로세스 개선 : 조직적으로 최적화된 프로세스를 적용하여 다시 피드백을 받아 개선

■ SPICE (Software Process Improvement & Capability Determination) - ISO/IEC TR 15504

• 여러 프로세스 개선 모형을 국제 표준으로 통합한 ISO의 소프트웨어 프로세스 모형
• Level0 (Incomplete : 불완전) - 프로세스가 부재하거나 목적 달성 실패
• Level1 (Performed : 수행) - 프로세스가 구현되어 목적 달성
• Level2 (Managed : 관리) - 프로세스가 관리되고, 작업 산물이 확립 / 통제 / 유지 관리된다.
• Level3 (Established : 확립) - 표준 프로세스를 기반으로 프로세스가 사용된다.
• Level4 (Predictable : 예측) - 프로세스가 정의된 한계선 내에서 일관성 있게 수행된다.
• Level5 (Optimizing : 최적화) - 프로세스가 지속적으로 개선된다.

23. 응용 통제

■ 응용 통제의 목적

• 무결성 (정확성 + 완전성 + 일관성) 및 승인

■ 생성 및 입력 통제

• 원시 문서의 서식 설계를 통한 오류 절감
• 거래 개시자에 의한 데이터 확인 및 관리자 승인
• 원시 문서 접수 및 배치 레지스터에 등록
• 배치 통합 합계 계산 → 문서, 금액, 해시, 항목 합계
• 키 검증 (Key verification)
  • 독립적인 입력 직원들이 각자 입력 후 그 결과를 상호 비교
  • 잊어버린 패스워드나 PIN (Personal Identification Number)를 재생성할 때 : 사용자가 직접 두 번 입력한다.

■ 확인 및 편집 → 처리의 무결성을 확보하기 위한 예방 통제

• 순서 체크 (완전성 통제)
• 한도 체크 및 범위 체크 (정확성 통제)
• 합리성 체크 (정확성 통제) : 합리적 빈도/숫자와 부합함을 검증한다.
• 논리적 체크 (정확성 통제) : 필드 간에 관계를 체크한다. → 예) 부인과 질환으로 인한 보험료 청구는 여성만 가능
• 타당성 체크 (정확성 통제) : 제시한 값들 중에서 선택하게 한다.
• 테이블 검색 (정확성 통제) : 마스터 파일에 존재하는지 검증한다.
• 존재성 체크 (정확성 통제) : 존재하는 값들에서만 선택하게 한다. → 예) 유호 거래처 목록에서 삭제된 걸래처는 선책 할 수 없다.
• (셀프) 체크 디지트 (정확성 통제) : 신용 카드나 계좌 번호 마지막 자리에 포함된 숫자. 번호의 자리 바뀜 또는 필사 오류를 검증한다.
• 완전성 체크 (완전성 통제) : 필수 입력 항목의 누락을 검증한다.
• 중복성 체크 (완전성 통제) : 이미 존재하는 거래인지를 검증한다.

■ 처리 통제

• 일부 확인 및 편집 기법들이 처리 통제에 사용될 수 있다.
• 실시 간 합계 (Run-to-tun totals) : 특정 처리 단계마다 데이터 값들을 지속적으로 검증한다. → 예) 마스터 파일의 갱신 전후의 합계 비교
• 예외 보고서 (Excption report) : 예외적 거래 및 처리를 보고한다. → 승인 및 입력 통제가 취약할 경우 예외 보고서 검토가 중요하다.

■ 데이터 파일 통제

• 내부 및 외부 라벨링
• 오류 보고서 및 거래 로그
• 사전/사후 이미지 : 거래 처리의 영향을 추적할 수 있게 해 준다.
• 일-대-일 체크 : 개별 원시 문서와 처리된 문서 목록을 비교한다.

■ 출력 통제

• 안전한 장소에서의 출력 및 출력 오류의 처리
• 법적 요구 기간 동안의 안전한 문서 보존
• 보존 기간이 매우 긴 경우 저장 매체의 노후화를 고려해야 한다.
• 데이터 통제 그룹에 의한 제한적 대조 및 조정
• 기밀문서 출력 시 사용자 코드 입력을 요구해야 한다.
• 적절한 수령자들에게만 보고서 배포, 인수인계 서명

■ 온라인 거래에 대한 데이터 무결성 체크

• Atomicity (원자성) : 거래는 전혀 처리되지 않거나 완전히 처리되어야 한다.
• Consitency (일관성) : 모든 무결성 규칙은 일관성 있게 적용되어야 한다.
• Isolation (분리성) : 한 거래의 데이터 접근은 타 거래와 분리되어야 한다.
• Duration (지속성) : HW/SW 장애에도 불구하고 완료된 거래 처리는 데이터베이스에 항구적으로 반영되어야 한다.

24. 응용 시스템 데스트를 위한 감사 기법

■ 프로그램 로직 분석

• Snap Shot
  • 처리 값들의 변화 과정을 관찰하여 프로그램 로직을 분석한다.
• Tracing and Mapping (추적과 매핑)
  • 실행되지 않는 코드를 식별하고, 효율성을 평가한다.
• Tagging and Tracing (태깅 및 추적)
  • 거래에 식별자를 붙여, 실행되는 명령어들의 증적과 상태 변화의 순서를 보여 준다.

■ 응용 통제 테스트

• Test Data
  • 변칙적 루틴 실행을 적발하는 데 유용하다.
  • 정보시스템 환경에 대한 많은 지식이 필요하지 않다.
  • 업무 시간에는 적용할 수 없으며, 운영자의 도움이 필요하다.
• ITF (Integrated Test Facility : 통합 테스트 시설)
  • 변칙적 루틴 실행을 적발하는 데 유용하다.
  • 업무 시간에도 테스트 데이터를 입력하여 프로그램 처리 무결성을 검증할 수 있으며, 운영자의 도움을 받지 않아도 된다.
  • 테스트 데이터가 실제 데이터를 손상시킬 수 있다.
• Parallel opertation (병렬 처리) 또는 Parallel test (병렬 테스트)
• Parallel Simulation (병렬 시뮬레이션)
  • 실제 처리 결과를 감사용 프로그램의 처리 결과와 비교한다.

■ 응용 통제 테스트

• EAM (Embedded Audit Module : 내부 감사 모듈)

25. 업무 응용 시스템

■ 전자상거래 (EC)

통제 목적	통제 대책
입증 (Authentication)	디지털 서명, 공개키 기반 구조 (PKI)
기밀성 (Confidentiality)	암호화, 보안 프로토콜
무결성 (Integrity)	디지털 서명 (또는 해시 함수)
가용성 (Availability)	방화벽, 데이터 백업, 업무 연속성 계획
책임 (Accuntability)	거래 로그, 활동 로그
부인방지 (non-Repudiation)	디지털 서명, 공개키 기반 구조 (PKI)

■ 전자 문서 교환 (EDI : Electronic Data Interchange)

• 구성 요소
  • Communication handler : 메시지 송수신, 라우팅 검증
  • EDI translator : 메시지 포맷의 변환
  • Application interface : 기능적 수령 증명 생성, 데이터 매핑
  • Application system : 거래의 처리
• EDI 메시지
  • Functional group header (기능적 그룹 헤더)
    • Transaction set count totals : 기능적 그룹에 포함된 메시지 (=트랜잭션 셋)의 개수이다.
    • Batch control totals
  • Transaction set trailer
    • Segment count totals : 메시지 (=트랜젝션 셋) 내의 세그먼트 개수이다.
  ■ 기타 업무 응용시스템
  • 이메일 → 라우터는 패킷의 목적지 IP를 기초로 라우팅 한다.
  • POS (Point of Sales) 시스템
  • Integrated Manufacturing System (통합 제조 시스템)
  • EFT (Electronic Fund Transfer : 전자 자금 이체) → 자금 이체의 효율성 향상
  • 전자 뱅킹
  • 전자 금융 (e-Finance)
  • 전자 지불 시스템 (Payment system)
  • 통합 고객 파일
  • 사무 자동화
  • ATM (Automatic Teller Machine)
    • 거래 내역과 이체 내역의 주기적 대조가 중요한 통제이다.
    • 고객 식별 및 기밀성 확보를 위한 통제를 검토한다.
  • 공조 처리 시스템 → 타 시스템의 응용을 이용할 수 있게 한다.
  • 음성 응답 주문 시스템
  • 구매 회계 시스템 : 매입 채무 처리, 수령 상품 처리, 주문 처리
  • 이미지 처리 : 문서의 이미지를 스캐닝하여 저장한다.
    • 스캐닝 품질을 위하여 스캐닝 절차가 중요하다.
    • 파일 명과 이미지 내용을 정리한 인덱스의 무결성이 중요하다.
  • 전문가 시스템 (ES)
    • 조직화된 결정을 지원한다.
    • 추론 엔진이 핵심 모듈이다
  • 데이터 웨어 하우스
    • 다량의 데이터를 삭제하지 않고 추가하기만 한다.
    • Data mining을 통해 원하는 지식을 얻을 수 있다.
  • 의사결정 지원 시스템 (DSS)