CISA domain 3 정리

도메인 3의 주요 목적은, 

- 응용프로그램을 개발하고, 변경하고, 기반기술 구조를 바꿀 때 사용하는 정보시스템의 구입, 개발, 적용 시의 핵심 프로세스와 방법론을 이해하는 것이다. 

- CISA 시험에서 12% 즉, 약 18문제가 출제된다. 비중이 제일 적은 도메인이기도 하다. 

# 3A: 정보시스템 획득과 개발

1. 프로젝트 경영관리

- 프로젝트 관리구조 관리 원칙과 절차 등과 같은 기본 요소를 알아야 한다. 

- 프로젝트 관리절차는 프로젝트 헌장으로 시작하여 프로젝트 완료보고로 끝난다. 

- 대규모 프로젝트의 요청을 접수하고 사업 우선순위를 결정하는 곳은 IT 운영위원회이다. 

- IT운영위원회에서는 프로젝트 매니저(PM)를 정해야 한다. 그리고 이 PM 에게 프로젝트 운영에 관한 모든 권한을 부여하고 관련 필요 인력을 제공해야 한다. 

- 프로젝트 관리 책임

   - 프로젝트 운영위원회 

      - 프로젝트 산출물과 비용, 일정에 대한 최종책임을 진다. 

      - 운영위원회의 모든 위원은 부서의 대표로서 의사결정에 관한 모든 권한을 가지고 있어야 한다. 

      - 위원장은 프로젝트 후원자가 맡으며, 프로젝트에 대한 소유관과 책임을 함께 보유한다. 

        * 프로젝트 후원자: 프로젝트에 필요한 자금을 지원하고, 프로젝트 성공을 판정하는 측정값을 결정한다. 후원자는 일반적으로 개발하는 응용프로그램을 주로 사용하게 되는
                                       비즈니스 부서의 최고 관리자를 말한다. 

    - 사용부서 관리자: 시스템을 소유하는 당사자로, 사용부서의 관리자는 시스템 산출물이 설계에 맞게 구현되어 있는지 검토하고 승인하는 비즈니스를 수행. 

    - QA

       - 각 단계 종료시점에서 단계와 결과 산출물을 점검하고 요구사항과 일치하는지 확인. 맨 마지막 단계에서 확인하는 게 아니다. 각 단계에서 확인하는 거다. 

       - SDLC(시스템개발 생명주기)를 얼마나 잘 준수하였는지 점검하여, 차이점 발견. 이렇게 하는 이유는 이를 단계별로 점검하지 않으면, 나중에 차이가 많이 발생하여 이를 보완하고자 하는 

          비용이 엄청 커지기 때문에 QA가 각 단계별로 involved 되어서 진행하는 것이 전체적으로 비용을 절약하는 방법이다. 

- 포트폴리오: 한 회사가 수핼하는 모든 프로그램과 프로젝트를 말한다. 

- 프로그램 : 프로젝트의 집합

- PMO (프로젝트 관리 사무소) 는 프로젝트 진행절차만 관리하고 내용은 관리하지 않는다.   

- 프로젝트 포트폴리오 관리 목표

  - 포트폴리오 전체 결과의 최대화

  - 프로젝트 우선순위 결정과 작업일정관리

  - 내외부 자원 조정

  - 모든 프로젝트에 지식 전파

- 포트폴리오 관리를 위해선 포트폴리오 데이터베이스가 필수이다. 왜냐하면 여기에 프로젝트 주관자, 일정, 목표, 프로젝트 형태, 현황, 비용 등 관련 데이터가 다 있기 때문. 

  포트폴리오 보고서에는 수익위험 매트릭스, 포트폴리오 진행 그래프가 있어야 한다. 

  -> 반대로 얘기하자면 IT 감사인이 포트폴리오를 이해하고자 한다면, 먼저 포트폴리오 데이터베이스부터 검토해봐야 할 것이다. 

- 프로젝트 계획단계에서는 

   - 프로젝트 범위가 결정되어야 하고, 

   - 작업의 실행순서, 기간, 일시, 우선순위가 결정되어야 하고, 

   - 필요자원이 결정되어야 하며,

   - 소요예산이나 비용, 장소, 장비, 노무비, 서비스료, 재료비 등 재원이 결정되어야 한다. 

그렇다면 IT 시스템 획득과 개발 원가 예측은 어떻게 할까? 

1. 가장 빠르게 구하고 싶으면, 과거 프로젝트 정보를 활용하여 신규 프로젝트 예산을 추정한다. 즉, 비슷한 사업을 활용하여 총 합계만 예측한다.

2. 모수를 활용한 예측 - 조금 더 정확하게 하고 싶으면, 비슷한 사업의 세부 데이터들의 통계 데이터를 활용하여 새 프로젝트에 대입하여 예측한다

3. 원가 합계 방식 예측 - 새 프로젝트를 셍사하게 분석하여 개별 행위의 각각 원가를 산정하여 예측. 시간이 아주 많이 걸린다. 

4. 실제 원가를 이용한 예측 - 과거에 수행한 프로젝트에서 발생한 원가를 이용하여 추산

소프트웨어 규모 예측은 어떻게 할까? 

- 심플하게는 소스코드 라인수와 같은 단일관점 추정값을 사용했으나 ,요샌 이렇게 할 수가 없다. 

- 따라서, 다중 모듈과 수많은 입출력 값으로 구성된 복잡한 응용프로그램 개발할 때의 개발 공수는 기능점수분석(Function Point Analysis) 로 계산한다. 

  FPA는 비즈니스용 응용프로그램 규모 예측하는 데에만 잘 맞고, OS나 프로세스 관리, 통신, 엔지니어를 비즈니스에서는 잘 맞지 않아 이 때는 COCOMO 모델이나 디마르코 왓슨펠릭스 점수법을 쓴다. 

  여하튼 복잡한 응용프로그램 개발 공수에서는 기능점수분석을 쓴다는 것만 알아두면 좋겠다. 

프로젝트 일정관리 방법은? 

간트차트, CP (Critical Path) 방법, 프로그램 평가 리뷰방법(PERT), 시간상자(time box) 관리 이 있다. 

1. 간트차트는 세부과업 착수, 종료 시점을 시간대별로 기록한 도표이다. 

2. Critical Path 는 프로젝트에서 단위작업을 연결했을 대 가장 길게 연결되는 작업경로로, 이 경로는 핵심업무들이기 때문에 스케줄상 조정할 수가 없다. 

    Critical Path를 이용하면 모든 자업이 예상대로 진행되었을 때 언제 가장 빨리 프로젝트를 완료할 수 있는 지 가장 빠른 시간을 추정할 수 있다. 그 이외의 것은 슬랙으로, 이는 가장 늦게 착수해도 프로젝트에 문제가 없는 시간과 가장 빨리 착수할 수 있는 시간의 차이로, 핵심 업무들은 아니다. 

3. PERT는 CPM 와 비슷한데, 작업시간 추정치를 3개를 사용한다는 점에서 다르며, 주로 의약품과 같은 매우 불확실한 사업 관리할 때 많이 사용한다. 간트보다는 훨씬 정교하다. 

PERT가 CPM보다 나은 점은 추정값이 통계적으로 베타분포를 따르기 때문에, 프로젝트 총기간을 신뢰구간을 반영하여 확률적으로 예측할 수 있다는 점이다.  

4. 시간상자관리

    - 매우 짧고 확정된 시간 내에 한정된 자원을 사용해서 소프트웨어 산출물 정의하고 적용하는 프로젝트 ㄷ관리기법

    - 매우 짧은 기간동안 핵심기능 완성하려고 할때 사용할 수 있으며, 프로젝트 비용이 예산 초과하는 일을 막거나 완성이 지연되는 걸 방지할 수 있다. 

     - 다만, 시스템 테스트와 사용자 인수테스트를 동시에 진행한다. 

프로젝트 통제와 점검

범위변경관리, 리소스사용관리, 위험관리 등을 해야한다. 

#범위변경관리

- 프로젝트 범위 관리하기 위해선 WBS(Work Breakdown Structure, 작업분해도) 로 세심하게 문서화해야 한다. 

- WBS는 프로젝트 계획단계나 기준선 확보단계의 주요 산출물이다. 

- 비즈니스 범위 변경 -> 필수 사업활동 변경 -> 예산과 사업종료일 영향 받음. 

- 변경사행 발생 -> 프로젝트 관리자에게 변경서 제출 -> 변경자문위원회가 변경요청서 평가 후 변경 승인 여부 결정 -> 프로젝트 매니저가 프로젝트 계획서 최신상태로 업데이트 -> 변경된 프로젝트 수정계획서를 프로젝트 후원자에게 보고 -> 공식승인 획득

#리소스 사용관리 

- 리소스 사용 = 절자에 따라 프로젝트 예산 사용하는 것

- 예산사용이 올바른 세부 과업에 집행되는지 확인하기 위해 예산 사용량을 측정하는 동시에 생산성도 점검해야 하는데, 이 때 획득가치분석(EVA, Earned Value Analysis) 를 이용한다. 

   * EVA 는 범위,일정,성과를 종합적으로 감시하는 데 좋은 방법으로 원가통제에 활용될 수 있다. 

프로젝트 관리에 대해 감사인은 만약 통제가 부족하고 절차가 무질서한 것을 발견하면, 프로젝트팀과 고위관리자에게 결함이 발생했다는 권고를 해야 한다. 

2. 비즈니스 사례 및 타당성 분석

- 프로젝트의 지속여부를 결정하는데 필요한 정보는 비즈니스 사례이다. 

- 개발타당성을 뒷받침해주는 것이 바로 비즈니스 사례. 

- 비즈니스 사례는 프로젝트의 어느 한 단계에서만 필요한 것이 아니라, 전 기간동안 의사결정의 핵심요소이다. 

  프로젝트의 어떤 단계에서라도 비즈니스상 타당성이 없는 것으로 드러나면 프로젝트가 중단될 수 있다. 

3. 시스템 개발 방법론

# 폭포수 모델

- 전통적인 시스템 개발 라이프사이클 모델

- 요구사항이 잘 변하지 않고 상세하게 정의되어 있는 프로젝트에 사용하기 적합

- 개발 초기에 시스템 아키텍처를 빨리 결정할 수 있다는 것이 장점

- 스크린 화면의 시제품을 이용하여 사용자 요구사항과 디자인을 완료할 수 있는 웹 응용프로그램 개발에 잘 맞음. 

# V모델 (검증과 유효확인)

- 개발과 테스트의 밀접한 상호 관계를 강조

- 사용자 요구사항   ---------------------------- 인수테스트

      기능요구사항     --------------------------시스템테스트

         기본설계           ----------------------  통합테스트

           상세설계           ------------------- 단위테스트

                                          코딩

# 소프트웨어 기준선

- 소프트웨어 기준선은 디자인 단계에서 더 이상 디자인 변경을 허용하지 않는 한계선

- 요구사항 변경을 통제하여 개발단계 내내 추가되는 비즈니스 범위 확대를 막을 수 있다. 

- 소프트웨어 설계 단계가 기준선 관리를 수행하기 가장 좋은 단계임. 

# 프로그램 디버깅

- 프로그램 개발 단계에서 프로그램을 테스트 환경에서 돌리면 많은 결함이 발견됨.

- 따라서 디버깅을 통해 코딩 결함을 발견하고 수정해야 함. 

- 컴파일러는 디버깅 도구로 뿐류하지 않음. 디버깅 종류는 로직경로 모니터, 메모리 덤프, 출력분석기가 있음.

   - 로직경로 모니터: 프로그램 수행한 이벤트 순서에 대한 보고서를 제공하여 로직에러 찾는 단서를 줌

   - 메모리 덤프: 프로그램이 정지하거나 실패했을 때의 메모리 모습을 보여줌. 여기서 데이터 값이나 파라미터 값 불일치하는지 점검할 수 있음. 

   - 출력분석기: 예상결과와 실제결과를 비교하여 원인분석하는데 사용

# 적용 후 리뷰

- 사용자 요구사항과 비즈니스 요구사항 충족하는지 평가

- 접근통제 적절하게 이루어지는지 평가

- 예상비용과 수익 ROI 분석결과 평가

- 시스템 불편사항 결함사항 점검하여 권고사항 제시

- 방법론, 표준, 기법 잘 준수했는지 평가

- 적절한 개발방법 사용했는지 평가

    

4. 통제확인과 설계

# 3B: 정보시스템 구현

1. 테스트 방법론

2. 구성 및 배포 관리

3. 시스템 이관, 인프라 설치, 데이터 전환

4. 적용 후 검토