Chatpter 03 계획 01 계획의 이해 02 문제의 정의 03 타당성 분석 04 개발 비용 산정

Presentation on theme: "Chatpter 03 계획 01 계획의 이해 02 문제의 정의 03 타당성 분석 04 개발 비용 산정"— Presentation transcript:

1 Chatpter 03 계획 01 계획의 이해 02 문제의 정의 03 타당성 분석 04 개발 비용 산정
요약 연습문제 05 비용 산정 기법 1 : 하향식 산정 기법 06 비용 산정 기법 2 : 상향식 산정 기법 07 비용 산정 기법 3 : 수학적 산정 기법 08 일정 계획 09 위험 분석

2 체계적인 계획을 세우는 방법을 알아본다. 소프트웨어 개발 비용 산정에 대해 알아본다. 기능 점수FP 방법에 대해 자세히 살펴본다. 프로젝트 일정과 위험 분석 방법에 대해 알아본다.

3 Section 01 계획의 이해

4 1. 계획의 이해

5 2. 소프트웨어 개발 계획 소프트웨어 개발 계획 계획 없는 소프트웨어 개발 비용, 기간, 자원 계획 필요
일정 지연, 비용 초과, 품질 저하 → 유지보수 비용 증가

6 Section 02 문제의 정의

7 1. 문제의 정의 문제 정의 문제 정의를 위한 필요 사항 소프트웨어 개발의 첫 작업 무엇을 개발할 것인지 명확히 정의
개발 범위를 결정 → 프로젝트의 초기 타당성과 초기 계획을 작성할 수 있는 기초로 활용 문제 정의를 위한 필요 사항 개발하고자 하는 영역의 배경 지식 필요하다. 문제를 파악하기 위해 현재 운영 중인 시스템을 사용해본다. 실무 담당자와 면담하여 자료를 수집한 후 면밀히 분석해본다.

8 Section 03 타당성 분석

9 1. 타당성 분석(1) 경제적 타당성economic feasibility 기술적 타당성technical feasibility
경영자: 투자 효율성cost benefit analysis에 관심 분석가: 투자 대비 효과 검토 후 경영자에게 정확한 정보 제공 시장 분석을 통한 시장성marketability 확인 → 개발 여부 판단 기술적 타당성technical feasibility 현재의 기술로 사용자가 요구하는 기능을 구현할 수 있는지 검토 하드웨어 성능이 개발에 지장은 없는지 검토 개발자의 기술력에 문제가 없는지 검토

10 1. 타당성 분석(2) 법적 타당성legal feasibility
개발용 소프트웨어와 도구의 사용이 법적으로 문제가 없는지 검토 지적 소유권과 프로그램 보호법이 강화되었으므로 법적인 문제를 꼭 검토

11 Section 04 개발비용 산정

12 1. 개발 비용 산정

13 2. 개발비 산정의 어려움(1) 전자 제품 생산 비용 예측 건축 비용 예측 생산 제품 형상의 명확화
생산에 투입되는 자재 개수 및 가격의 명확화 → 제조 원가의 명확화 건축 비용 예측 자재비, 인건비의 정확한 예측 가능 전체 비용 정확한 산출(평당 가격 Ⅹ 평수)

14 2. 개발비 산정의 어려움(2) 전자 제품 생산 비용 예측 건축 비용 예측 생산 제품의 형상의 명확화
생산에 투입되는 자재의 개수, 가격의 명확화 => 제조 원가의 명확화 건축 비용 예측 자재비, 인건비의 정확한 예측 가능 전체 비용 정확한 산출(평당 가격 Ⅹ 평수)

15 2. 개발비 산정의 어려움(3) 소프트웨어 개발 비용 예측 가전제품 생산이나 건축 공사와 달리 사람(개발자)이 중심
개발자의 능력에 따른 생산성의 차이 기간과 품질에 영향 다양한 개발 프로세스로 인한 표준화/자동화의 어려움 다양한 생산성과 품질 → 명확한 개발비 산출의 어려움

16 3. SW 개발 비용에 영향을 주는 요소(1) 프로그램 자질 소프트웨어 복잡도 소프트웨어 크기
초급 프로그래머와 고급 프로그래머의 생산성 차이가 큼 → 프로그램의 자질: 개발 비용에 영향을 줌 소프트웨어 복잡도 브룩스의 법칙: 애플리케이션 개발 < 유틸리티 개발 < 시스템 프로그램 개발 → 소프트웨어 복잡도: 개발 비용에 영향을 미침 소프트웨어 크기 참여 인력 증가, 개발 기간 길어짐, 복잡도 커짐 → 소프트웨어 규모: 개발 비용에 영향을 미침

17 3. SW 개발 비용에 영향을 주는 요소(2) 가용 시간 요구되는 신뢰도 수준 기술 수준
관리자들의 잘못된 생각: 인력/자원 증가는 개발 기간 단축 보헴: “정상적인 계획에서 최대 75%가 줄일 수 있는 한계” 요구되는 신뢰도 수준 높은 신뢰도의 소프트웨어 개발: 개발 비용의 증가 기술 수준 고급언어 사용: 저급 언어의 사용보다 5~10배의 생산성 증가

18 Section 05 비용 산정 기법 1 : 하향식 산정 기법

19 1. 하향식 산정 기법 전문가 판단 기법 델파이 기법 보완 경험이 많은 전문가가 개발 비용을 산정 신뢰성 높음
경험이 많은 전문가가 개발 비용을 산정 신뢰성 높음 짧은 시간에 개발비를 산정하거나 입찰에 응해야 하는 경우 많이 사용 단점: 수학적 계산 방법보다 경험에만 의존할 경우 부정확할 수 있음 델파이 기법 보완

20 Section 06 비용 산정 기법 2 : 상향식 산정 기법

21 1. 상향식 산정 기법 상향식 산정 기법 ① 원시 코드 라인 수LOC 기법
세부 작업 단위별로 비용 산정한 후 전체 비용 합산 단점: 수학적 계산 방법보다 경험에만 의존할 경우 부정확할 수 있음 ① 원시 코드 라인 수LOC 기법 원시 코드 라인 수의 비관치, 낙관치, 중간치를 측정 후 예측치를 구해 비용 산정 ② 개발 단계별 노력effort per task 기법 생명주기의 각 단계별로 노력(M/M)을 산정

22 2. 원시 코드 라인 수 기법 LOC 기법 예측치 계산 비관/낙관/기대치 측정 비용 산정(노력, 개발 비용, 생산성)
• 낙관적 : 한 모듈의 라인 수를 가장 적게 생각할 때의 예상 라인 수(가중치 1 부여) • 비관적 : 한 모듈의 라인 수를 가장 많게 생각할 때의 예상 라인 수(가중치 4 부여) • 보통 : 한 모듈의 라인 수를 보통이라고 생각할 때의 예상 라인 수(가중치 1 부여) • 추정 LOC : (낙관치+(4X중간치)+비관치)/6

23 3. 개발 단계별 노력(M/M)기법 LOC 실제 소프트웨어 개발 개발 단계별 노력 기법
코딩뿐 아니라 요구 분석, 설계 등의 단계에서도 인력과 자원이 많이 필요 개발 단계별 노력 기법 M/M을 소프트웨어 개발 생명주기의 각 단계에 적용하여 단계별로 산정 장점: 코딩만 대상으로 산정하는 LOC보다 더 정확 LOC 보완

24 Section 07 비용 산정 기법 3 : 수학적 산정 기법

25 1. 수학적 산정 기법 ① COCOMO 방법 ② Putnam방법 ③ 기능 점수(FP) 방법 상향식 비용 산정 기법
경험적 추정 기법 또는 실험적 추정 기법 ① COCOMO 방법 SW 규모(LOC) 예측한 후 SW 종류에 따라 각 비용 산정 공식에 대입하여 비용 산정 ② Putnam방법 소프트웨어 생명주기의 전 과정에 사용될 노력의 분포를 가정해 주는 ③ 기능 점수(FP) 방법 기능 점수를 구한 후 이를 이용해 비용 산정

26 2. COCOMO 방법(1) COCOMO 방법 개발비 산정 시 고려 사항 준비된 식에 대입 LOC추정 M/M예측
라인수 중심의 개발비 산정 개발비 산정 시 고려 사항 프로그램 유형(난이도)에 따른 가중치 준비된 식에 대입 LOC추정 M/M예측

27 2. COCOMO 방법(2) 네 가지 특성에 따른 15가지 분류

28 2-1 COCOMO 방법을 이용한 총 개발 기간 산정 과정
① 가중치 반영하기 프로그램의 규모 LOC에 가중치가 반영된 초기 개발 인건비M/M 산정 ② 보정 계수 반영 하기 ③ 총 개발 기간 산정하기 유형에 따른 가중치 부여 LOC 예상 M/M계산 노력 조정 수치 반영 가중치 반영된 M/M P/M계산 동일 상수 적용 계산된 P/M 총 개발 기간 산정

29 2-2 프로젝트 유형 단순형 프로젝트 중간형 프로젝트 내장형 프로젝트 복잡도와 난이도가 비교적 높지 않은 업무용 소프트웨어
크기는 중소 규모 정도, 크기는 50KDSI 이하 중간형 프로젝트 규모나 복잡도가 중간급 정도, 크기 300KDSI 이하 운영체제, 데이터베이스 관리 프로그램 내장형 프로젝트 자동화 기기, 전자 제품과 같은 하드웨어와 밀접하게 관련 있는 소프트웨어 크기 300KDSI 이상

30 2-3 가중치 반영하기(1) 개발 인건비의 초기 예측 값 산출 방법

31 2-3 가중치 반영하기(2) 유형별 M/M 단순형 < 중간형 < 내장형

32 노력조정 수치EAF = 필요한 각 항목에 승수 값을 모두 곱한 값
2-4 보정 계수 반영하기(1) 노력 조정 수치EAF: Effort Adjustment Factor 보정에 사용되는 값 (예) 노력조정 수치EAF = 필요한 각 항목에 승수 값을 모두 곱한 값 개발하려는 소프트웨어에 요구되는 신뢰도가 높고(1.15), 매우 복잡하며(1.30), 소프트웨어공학 기술을 거의 사용하지 않고(1.24), 요구되는 개발 일정이 매우 촉박하고(1.10), 다른 요소들은 보통(1.00)일 경우의 노력 조정 수치? EAF = 1.15×1.30×1.24×1.10=2.04 노력 조정 수치 반영 가중치 반영된 M/M P/M계산

33 2-4 보정 계수 반영하기(2)

34 PM=3.0× (KDSI)1.12×EAF = 3.0× (60) 1.12×2.04 = 600.179
2-4 보정 계수 반영하기(3) 노력 조정 수치가 반영된 노력(P/M) (예) 만일 개발하려는 소프트웨어의 KDSI가 60이고, 소프트웨어는 중간형이며, 노력 조정 수치(EAF)가 2.04라면 노력(E)? PM=3.0× (KDSI)1.12×EAF = 3.0× (60) 1.12×2.04 =

35 2-5 총 개발 기간 산정하기 총 개발 기간TDEV: Total DEVelopment time
(예) 만일 개발하려는 소프트웨어의 KDSI가 60이고, 소프트웨어는 중간형이며, 노력 조정 수치(EAF)가 2.04라면 노력(E)= 이다. 이 때 총 개발 기간은? TDEV=2.5 ×(PM)0.35 = 2.5 ×( ) 0.35 =

36 3. COCOMO II 방법 COCOMO의 문제점: (계획 단계)원시코드 라인수 예측

37 3-1 프로젝트 진행 정도에 따른 분류 [1단계] 애플리케이션 합성 모델application composition model
[2단계] 초기 설계 모델early design model 초기 설계 단계에서 예측 값을 구한다. 1단계보다 더욱 정확한 예측이 가능 [3단계] 구조 설계 이후 모델post-architecture model 기능 점수를 바탕으로 한 LOC를 추정하여 소프트웨어 규모를 산정 객체 점수 산출 UI 개수 계산 SW 규모 산정

38 4. 기능 점수 산정 방법(1) 산정 근거 기능 점수function point
4. 기능 점수 산정 방법(1) 산정 근거 기능(입·출력, 데이터베이스 테이블, 인터페이스, 조회 등)의 수 → 라인 수와 무관하게 기능이 많으면 규모도 크고 복잡도도 높다고 판단 사용자관점에서 소프트웨어의 기능 정량화 => 개발 비용 산정 기능 점수function point 소프트웨어 기능의 크기를 측정하는 단위 (즉) 소프트웨어의 기능이 얼마나 복잡한가를 상대적인 점수로 표현하는 것

39 4. 기능 점수 산정 방법(2) 용도 특징 개발 시 비용 산정 유지보수 비용 산정 개발 시 필요한 자원 산정
4. 기능 점수 산정 방법(2) 용도 개발 시 비용 산정 유지보수 비용 산정 개발 시 필요한 자원 산정 특징 소프트웨어 규모를 측정하는 방법 기능적 요구 사항이 중심이 되는 측정 방법 소프트웨어의 요구 사항 복잡도를 측정 구현 관점 아닌 사용자 관점의 요구 기능을 정량적으로 산정 측정의 일관성 유지를 위해 개발 기술, 개발 방법, 품질 수준 등은 고려하지 않음 소프트웨어 개발에 사용되는 언어와 무관 소프트웨어 개발 생명주기의 전체 단계에서 사용 가능

40 5. 소프트웨어 기능 분류

41 6. 기능 점수 산정 방법 정규 기능 점수 법 간이 기능 점수 법 유형별 복잡도 계산 기능 도출 평균 복잡도 적용 기능 도출
6. 기능 점수 산정 방법 정규 기능 점수 법 설계 단계 이후에 사용하면 유용 간이 기능 점수 법 기획 및 발주 단계에서 사용 유형별 복잡도 계산 기능 도출 기능 점수 산정 평균 복잡도 적용 기능 도출 기능 점수 산정

42 7. 기능 점수 산정 방법의 장점 사용자의 요구 사항만으로 기능을 추출하여 측정 객관적인 요구 사항만으로 측정
7. 기능 점수 산정 방법의 장점 사용자의 요구 사항만으로 기능을 추출하여 측정 실제 구현 방법과 무관 객관적인 요구 사항만으로 측정 개발 방법이나 개발 팀과 무관 모든 개발 단계에서 사용 계획 단계뿐 아니라, 분석, 설계, 구현 단계에서도 사용 가능

43 8. 기능 점수 산정 방법의 단점 높은 분석 능력 필요 기능 점수 전문가 필요 내부 로직 위주의 소프트웨어에는 다소 부적합
8. 기능 점수 산정 방법의 단점 높은 분석 능력 필요 요구 사항으로부터 기능을 도출하려면 상당한 분석 능력이 필요 기능 점수 전문가 필요 이 방법을 잘 사용할 수 있는 기능 점수 전문가가 필요 내부 로직 위주의 소프트웨어에는 다소 부적합 사용자가 알 수 있는 기능으로 측정하기 때문에 내부 로직 위주의 SW 측정에는 부적합 개발 규모 측정에 적합 개발 규모를 예측하는 데 적합

44 9. 간이 기능 점수법 산정 평균 복잡도 가중치 간이 기능 점수법 5가지 유형에 적용된 복잡도에 대해 계산한 가중치의 평균값
9. 간이 기능 점수법 산정 평균 복잡도 가중치 5가지 유형에 적용된 복잡도에 대해 계산한 가중치의 평균값 5가지 유형: 내부 논리 파일, 외부 연계 파일, 외부 입력, 외부 출력, 외부 조회 간이 기능 점수법 프로젝트 초기 단계에서 평균 복잡도 가중치를 사용하여 소프트웨어 기능의 크기를 측정

45 10. 간이 기능 점수 산정 절차

46 10-1 측정 유형 결정 개발 프로젝트 기능 점수(개발 규모 측정)
프로젝트가 완료되어 최초 설치했을 때의 기능 크기를 산정 (즉) 프로젝트에서 사용자를 위해 제공된 모든 기능을 측정 개선(enhancement) 프로젝트 기능 점수(변경 규모 측정) 사용 중인 소프트웨어에 변경이 발생했을 때 변경된 부분의 기능을 측정 (즉) 완료된 프로젝트에서 추가, 수정, 삭제된 부분만 그 크기를 측정 애플리케이션 기능 점수(응용 규모 측정) 현재 운용 중인 애플리케이션의 기능을 측정 개발프로젝트 기능 점수에 개선 프로젝트 기능 점수까지 포함된 것

47 10-2 측정 범위와 애플리케이션 경계 식별(1)

48 10-2 측정 범위와 애플리케이션 경계 식별(2) 측정 범위에 포함될 요소(서브시스템)의 식별 애플리케이션 경계
측정 범위: 기능 점수를 측정하고자 하는 대상 측정 대상: 개발하고자 하는 전체 소프트웨어 또는 소프트웨어의 일부 시스템 애플리케이션 경계 금번 기능 점수를 계산하는 대상과 다른 애플리케이션이나 외부 사용자를 구분하는 경계 애플리케이션 경계 식별 시 주의 점 사용자 관점에서 경계 구분 개발자 관점(클라이언트/서버, 서버/비즈니스 로직/클라이언트 계층)으로 구분하면 안됨 애플리케이션의 경계의 크기가 적당해야 함

49 10-3 데이터 기능 점수 계산(1) 데이터 기능 점수 계산
내부 논리 파일(ILF)의 개수와 외부 연계 파일(EIF)의 개수를 계산하여 각각의 평균 복잡도(가중치)에 따라 데이터 기능 점수 결정

50 10-3 데이터 기능 점수 계산(2) 내부 논리 파일ILF: Internal Logical File
사용자가 등록/수정/삭제/조회를 하기 위한 대상 데이터베이스에 존재하는 데이터 모임(데이터베이스의 정보) 데이터베이스 정보: 기능 점수 측정 대상으로 애플리케이션 내부에서 파일로 유지 데이터베이스 테이블, 시스템 내부에서 다루는 파일, 클래스 등 애플리케이션에 존재하는 데이터를 논리적으로 모아놓은 것 금번 프로젝트에서 생성하여 관리하는 데이터 외부 연계 파일EIF: External Interface File 측정 대상 애플리케이션에서는 참조만 하고 다른 애플리케이션에서 유지되는 파일 다른 프로젝트에서 생성하였으나 금번 프로젝트에서 참조하는 데이터

51 10-3 데이터 기능 점수 계산(3) 데이터 기능 점수 = {(ILF 개수×7.5) +EIF 개수 +5.4)}
7.5: 내부 논리 파일의 평균 복잡도 5.4: 외부 연계 파일의 평균 복잡도

52 10-4 트랜잭션 기능 점수 계산(1) 트랜잭션 기능 트랜잭션 기능 측정 트랜잭션 기능 점수 입력, 출력, 조회
외부 입력, 외부 출력, 외부 조회의 횟수를 세는 것 트랜잭션 기능 점수 {외부 입력, 외부 출력, 외부 조회}의 개수 X 각각의 평균복잡도(가중치)

53 10-4 기능 유형(2) 외부 입력external input 외부 출력external output
데이터베이스에 데이터를 등록하거나, 수정·삭제하는 것 (예) 학생 정보 등록, 수정, 삭제 외부 출력external output 계산하는 로직을 거쳐 데이터나 제어 정보를 사용자에게 보여주는 기능 수학적 계산 로직이 하나 이상 존재하며 그에 따른 파생 데이터도 존재 (예) 학생 학점 조회 외부 조회external inquiry 로직이 필요 없고 DB에 존재하는 데이터를 찾아 그대로 표시만 해주는 기능 (예) 학생 주소 검색, 학생 정보 조회

54 10-4 트랜잭션 기능의 예(3) 트랜잭션 기능 점수 = {(EI개수 × 4.0) + (EO개수 × 5.2) + (EQ개수 × 3.9)} 4.0: 외부 입력의 평균 복잡도 5.2: 외부 출력의 평균 복잡도 3.9: 외부 조회의 평균 복잡도

55 10-5 미조정 기능 점수 계산 미조정 기능 점수UFP: Unadjusted Function Point
데이터 기능 점수 + 트랜잭션 기능 점수 단순히 기능적인 요구 사항에 대해서만 계산 여러 가지 특성에 대한 고려를 하지 않음

56 10-6 보정 전 개발 원가 계산 보정 전 개발 원가 미조정 기능 점수 X 기능 점수당 단가
기능 점수당 단가: 519,203원(출처: SW사업대가산정 가이드) 소프트웨어 개발 전체에 대한 기능 점수

57 10-7 보정 후 기능 점수 계산(1) 규모 보정 계수 애플리케이션 유형 보정 계수 규모에 따라 값을 보정
대규모: 복잡도 증가 생산성 하락 보정 계수를 높여 보정 기능 점수에 따라 달라진다. 애플리케이션 유형 보정 계수 소프트웨어 유형에 따라 복잡도가 달라 생산성도 달라지는 것을 보정

58 10-7 보정 후 기능 점수 계산(2) 언어 보정 계수 언어에 따라 생산성도 달라지므로 개발 언어에 따른 보정 계수 적용

59 10-7 보정 후 기능 점수 계산(3) 품질/특성 보정 계수

60 10-8 보정 후 개발 원가 계산(1) 학사 관리 개발 원가 계산의 예 보정 후 개발 원가
= 보정 전 개발 원가 ×(규모 보정 계수 × 애플리케이션 보정 계수 × 언어 보정 계수 × 품질/특성 보정 계수) 학사 관리 개발 원가 계산의 예

61 10-8 보정 후 개발 원가 계산(2)

62 Section 08 일정 계획

63 1. 일정 계획

64 1-1 SW 개발 프로젝트에서의 일정 계획 일정 계획
작업 순서 결정, 소작업의 개발 기간, 순서, 필요한 자원 등의 일정 계획

65 2. 작업 분할 구조도(1) 작업 분할 구조도(WBS: Work Breakdown Structure)
프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화하는 작업 프로젝트 구성 요소들을 계층 구조로 분류 프로젝트의 전체 범위 정의 프로젝트 작업을 세분화 작업 패키지(work package) 계층 구조에서 최하위에 있는 항목

66 2. 작업 분할 구조도(2)

67 2. 작업 분할 구조도(3) 작업 분할 구조도의 목적과 용도 • 사용자와 개발자 간의 의사소통 도구로 사용함.
• 프로젝트 업무 내역을 가시화할 수 있어 관리가 용이함. • 프로젝트 팀원의 책임과 역할이 분명함. • 필요 인력과 일정 계획을 세우는 데 기초로 활용함. • 개발비 산정 시 기초로 활용함. • 성과 측정 및 조정 시 기준선으로 활용할 수 있음.

68 3. 네트워크 차트 PERT/CPM WBS의 작업 순서, 소요 기간 등을 네트워크 형태의 그래프로 표현한 후 어떤 작업이 중요한지, 또 일정에 여유가 있는 작업은 어떤 것이지 찾아내 중점 관리를 해야 하는 작업을 명확히 하는데 사용 프로젝트를 완료할 수 있는 최소 기간은 얼마인지, 완료 기간을 맞추기 위해서는 각 작업을 언제 시작하고 완료해야 하는지, 지연되지 않으려면 어떤 작업에 특히 주의를 기울여야 하는지, 또 전체 프로젝트 완료 기간을 단축하기 위해서는 어떤 작업들을 단축하는 것이 가장 경제적인지 등 관리자의 고민에 답을 주기 위해 필요한 도구

69 4. 학사 관리 애플리케이션에 대한 CPM의 예

70 ① CPM 네트워크를 그린다

71 ② ES값을 구한다 ESEarliest Start Time
가능한 빨리 시작할 수 있는 시간으로, 선행 작업이 완료되었을 때 해당작업을 시작할 수 있는 가장 빠른 시점 ES 값을 구할 때는 맨 앞(작업 A)에서 끝 방향으로 가며 계산

72 ③ EF값을 구한다 EFEarliest Finish Time

73 ④ ES값을 구한다 LSLatest Start Time
어떤 작업을 늦어도 시작해야 하는 시간, 즉 가장 늦게 시작할 수 있는 시간 이 시간에 시작하지 않으면(이 시간보다 늦게 시작하면) 총 일정이 지연

74 ⑤ LF값을 구한다 LFLatest Finish Time 가장 늦게 시작할 수 있는 시간(LS)에 시작해 작업을 완료한 시간

75 ⑥ ST값을 구한다 STSlack Time ‘느슨한 시간’, ‘여유 있는 시간’

76 ⑦ 임계 경로를 구한다 임계 경로critical path [그림 3-13]의 그래프에서 여유 시간이 없는 경로

77 5. 간트 차트를 이용한 일정표 작성 간트 차트Gantt chart 프로젝트 일정 관리를 위한 바bar 형태의 도구

78 Section 09 위험 분석

79 1. 위험 분석

80 2. 위험 예방

81 3. 위험 관리 절차(1)

82 3. 위험 관리 절차(2) 위험 요소 식별

83 3. 위험 관리 절차(3) 위험 분석 위험 요소가 발생할 가능성과 영향력을 판단
과거 프로젝트에서 데이터와 위험을 분석한 경험이 많은 개발자에 의존해 판단 위험 발생 가능성의 척도 ‘매우 낮음(<10%), 낮음(10~25%), 보통(25~50%), 높음(50~75%), 매우 높음(>75%)’ 위험 발생 확률 상: 80% 이상, 중: 30~80%, 하: 30% 미만 영향력 재앙, 심각함, 해결 가능함, 경미함 등으로 분류 비용과 일정으로 분류: 상(20% 이상 초과), 중(5~20%), 하(5% 이하)

84 3. 위험 관리 절차(4) 위험 계획 수립 위험 감시 식별된 위험 요소의 위험을 관리하기 위해 전략을 찾는 과정
위험을 처리하는 위험 대응 방안 수립 위험 감시 식별된 위험 요소의 발생 확률과 변화 등을 관리 예측한 위험의 실제 발생 여부 확인 실전에서 위험 대응 방안의 적절성 여부 확인