CISA Domain 3 프로젝트, PERT, 개발절차

 

프로젝트 정관(헌장, Charter)

• 프로젝트 존재를 공식적으로 승인하고 자원 사용 권한 부여
• 고위 경영진 및 후원자 승인
• 포함 내용
  • 프로젝트 관리자 권한 및 수준
  • 비즈니스 케이스
  • WHAT, 무엇을 할 것인지

비즈니스 케이스, 사업 사례(Business case)

• 전략적 목적, 사업 쟁점을 해소하기 위해 대안의 필요성, 정당성, 기대효과를 설명
• 초기 사업 사례는 타당성 단계에서 작성(이사회와 고위 경영진 승인 필요)
• 주요 이정표(마일스톤) 마다, 단계 말에서 주기적으로 재검토
• 중간중간 변경될 수 있으며 변경 시 이사회에서 재승인

프로젝트 포트폴리오

• 모든 프로젝트의 집합
• 전사적으로 비용대비 효과 극대화 관건
• 필수 요건 : 프로젝트 포트폴리오 데이터베이스
• PMO가 관리

프로젝트 운영 위원회

• 이해상충 조정, 우선순위 결정, 위험 해소 방안 협의
• 구성 : CxO, 프로젝트 매니저
• 의장 : 프로젝트 후원자(소유권과 책임)

사용자부서 관리자

• 프로젝트와 프로젝트에서 만드는 시스템을 소유하는 당사자
• 설계서에 맞게 구현되었는지 검토하고 승인

---

소프트웨어 규모 산정

• 단일점 산정 방법 : SLOC(Source Line of Code) or KLOC(Kilo Lines of Code)
• 다중점 산정 방법

기능 점수 분석(FPA, Function Point Analysis)

• 사용자와 상호작용하는 입/출력 파일 인터페이스, 복잡성에 근거해 정보시스템의 크기 측정

간트 차트

• 가로 : 시간, 세로 : 프로젝트 활동 표시
• 각각 활동이 언제 시작하고 지속되는지 표현

PERT(Program Evaluation Review Technique)

• 서로 관련있는 활동 구분 후 시작부터 끝까지 관계를 네트워크로 정의
• 순차적 개념 뿐만 아니라 서로 선후 관계를 가질 수 있다.
• 선후일때 이전 작업이 끝나야만 진행 가능
• 핵심경로 CP(Critical Path)
  • 가장 긴 경로로 프로젝트 완료에 필요한 최소한의 기간
• 시간의 불확실성을 위해 확률 분포 사용

CPM(Critical Path Methodology)

• 개별활동의 지속시간은 평균 지속시간
• 경험적 예측을 통해 결정된 확정적 시간을 사용
• 여유 시간(Slack Time)
  • 이전 활동을 근거로 각 활동들의 최장 완료 시간 사이의 차이
  • 핵심 경로상에서의 여유시간은 0이다.

Time boxing

• 사전에 주어진 자원을 가지고 짧지만 변경불가능한 시간 내 완료할 SW를 정의하고 설치하기 위한 기법
• 통제할 수 없을 정도로 복잡한 문제를 해결하기 위해 RAD(Rapid App Dev), EUC(End User Computing)에 사용

---

 

소프트웨어 개발 수명 주기 모델

폭포수 기법

• 전통적인 접근법
• 정형화된 일련의 단계를 수행, 한번 수행된건 회귀하지 않는다.

증분적 모델

• 전체 개발 범위를 일정 범위로 분할 한 후 개발 우선순위를 두어 개발
• 이후 완성된 부분을 통합

반복적 모델

• 전체 개발 범위에 대해 분석-설계-개발-테스트 과정을 반복 수행
• 시스템 전체를 기본 구성만 갖춘 형태로 신속하게 개발하여 최초 버전을 완성
• 최초 버전에 사용자들의 검토 의견을 받아 최종 버전으로 완성

나선형 모델

• 증분적 개발 방법과 반복적 개발방법에 위험 분석 활동을 추가

 

프로젝트 수익성 평가

NPV(Net Present Value)

• 편익의 현재 가치-비용의 가치 = 순 현재가치 > 0
• 즉, 수익성(타당성) 있는 사업인지 객관적으로 판단 가능

ROI(Return On Investment)

• 투자 수익률 = 매출 - 비용 및 광고 투자 / 비용 및 광고 투자

---

 

SW 개발 절차

• 타당성 검토 : 기존 시스템을 수정할 지 개발할지 구입할지 결정
  • 기술적/경제적/법적 타당성을 검토
• 요구사항 정의(기본설계)
  
  • 프로젝트 착수 및 비용에 대해 경영진 승인 검토
  • 상용자 인수 테스트 사양서 검토
    • 인수 테스트 요구사항은 이 단계에서 도출
  • 내장 감사(EAM)이 필요한지 검토
  • 프로세스 모형화 : DFD, ERD
• 획득(소프트웨어 구매 시)
  • 벤더들의 제품 요구사항, 실적, 재무능력, 소스코드 제공여부, 유지보수 서비스 범위 등 정보를 요청하는 제안 요청서(RFP) 전달
  • 벤더들이 제출한 제안서를 수령한 다음 평가 이후 소수의 적격 업체 선정 후 계약 체결
  • 감사인의 역할
    • 적절한 보안 통제 확인(감사 증적, 패스워드 통제)
    • RFP 적합성 검증
• 설계(상세 설계)
  • 절차시스템을 구체적으로 정의
  • 하향방식으로 구조적 설계 기법 사용
  • UI/UX 결정
  • DB 설계
  • 테스트 계획
  • 소프트웨어 기준선 설정
  • 감사인의 역할
    • 사양서/테스트 계획 검토, 입출력 통제 확인
    • UI 설계 시 사용자 참여 검증
    • 모든 변경 사항에 대해 승인 검토
    • 설계 과정의 효과성 검토
    • 문서 검토(시스템, DB 사양서), 테스트 계획, 소프트웨어 변경 통제 절차서
• 개발
  • 감사인의 역할
    • 감사 증적 적합성 평가
    • 처리의 무결성 검증
    • QA 검토
    • EAM 검증
• 테스트
  • 드라이버, 스텁 : 인터페이스에 대한 테스트
  • 종류
    • 상향식 테스트
      • 개별 모듈을 테스트한 뒤 상위 단위로 통합해 가면서 테스트
      • 단위 테스트, 연계 테스트, 통합 테스트 순으로 진행
      • 드라이버/스텁이 필요 없다.
      • 모듈의 오류를 초기 발견 가능하다.
    • 하향식 테스트
      • 시스템 전체에서 개별 모듈로 관점을 좁혀 가면서 테스트
      • 일반적으로 잘 따르지 않는 접근법
      • 깊이 우선, 너비 우선 접근법 사용
      • 드라이버/스텁 사용
      • 인터페이스 오류 및 주요 기능 테스트 초기 확인 가능
    • 시스템 테스트
      • 사용자 요구사항을 하나의 시스템으로서 완벽하게 수행되는지 확인
        • 복구/보안/스트레스/성능 테스트
    • 인수 테스트
      • 사용자가 요구한 시스템이 개발된건지 사용자가 검증
        • QAT(품질 보증 테스트), UAT(사용자 승인 테스트)
    • 파일럿 테스트
      • 시스템 일부 또는 일부분만 예비적으로 테스트
      • 초기 개념 증명 (POC)도 일종의 파일럿 테스트
    • 회귀 테스트
      • 발견된 오류를 수정하거나 시스템을 변경한 후 새로운 오류가 발생했는지 확인하기 위해 이미 수행한 테스트를 다시 수행
    • 병행 테스트
      • 신규 시스템의 안정성을 기존 시스템과 비교
      • 기존 시스템의 처리 결과를 비교
      • 병행 시뮬레이션과는 다른의미므로 주의
    • 사회성(사교성) 테스트
      • 신규 시스템이 설치되면 기존 시스템에 부정적인 영향을 주는지 확인
• 구현
  • 최종 인수 테스트 수행/시스템 이관
  • 데이터 변환, 사용자 교육 및 훈련
• 구현 후 검토
  • 설계/개발이 잘됐는지 시스템에 대한 통제의 적절성 검증
  • 프로젝트 개발팀과 최종 사용자의 협조