5. 프로젝트 계획 및 통제.

Presentation on theme: "5. 프로젝트 계획 및 통제."— Presentation transcript:

1 5. 프로젝트 계획 및 통제

2 주요내용 프로젝트 계획서란? 프로젝트 팀 구성은 어떻게 해야 하는가? WBS란? 프로젝트 산정 기법은 어떤 것들이 있는가?
일정 계획 방식은 어떤 것들이 있는가? EVM이란? © 2008 Software Engineering

3 목차 강의 내용 팀 프로젝트 (7, 9주차) 프로젝트 계획서 프로젝트 팀 구성 WBS 프로젝트 산정 기법 일정 계획 방식
EVM 팀 프로젝트 (7, 9주차) 프로젝트 계획서 작성 및 제출 © 2008 Software Engineering

4 프로젝트 계획서 의미 프로젝트 관리자 뿐만 아니라 프로젝트 참여자 모두가 프로젝트를 진행해 가면서 참조하는 프로젝트의 중심이 되는 문서 작성 순서 프로젝트 관리자는, 프로젝트 태스크 파악 각 태스크를 수행하기 위해 필요한 노력 예측 인적 자원 및 기타 자원을 각 태스크에 할당 일정 계획 수립 프로젝트 참여자의 검토를 거쳐 합의 하에 프로젝트 채택함 © 2008 Software Engineering

5 IEEE 프로젝트 계획서 양식 © 2008 Software Engineering

6 프로젝트 계획서의 역할 및 중요성 프로젝트 진행 과정의 주기적 통제의 기본
주간, 월간 회의를 통해 점검 프로젝트가 크고 참여자가 많을수록 잘 짜여진 프로젝트 계획서가 중요함 프로젝트 계획서가 현실적으로 작성되어 전체 프로젝트 진행상황 파악에 크게 문제가 되지 않아야 함 © 2008 Software Engineering

7 프로젝트 팀 구성

8 프로젝트 팀 구성 팀 구성의 기준 팀 구성원의 역할 프로젝트 기간과 크기 프로젝트 팀장 분석 및 설계자 개발자
품질 보증 담당자 산출물 관리 담당자 테스팅 담당자 … © 2008 Software Engineering

9 팀장과 구성원의 2단계 구조 (1/2) 소개 프로젝트 책임자인 팀장은 상위 단계에, 나머지 참여자는 전부 다음 단계에 속함 일반적인 소규모 프로젝트가 가장 많이 취하고 있는 팀 구조 구조 책임 프로그래머 자문위원 (a) 조직 구성 (b) 의사 소통 경로 © 2008 Software Engineering

10 팀장과 구성원의 2단계 구조 (2/2) 역할 소개 단점 책임 프로그래머 팀원 팀장
팀의 운영에 대한 결정권한 및 운영에 대한 책임을 가짐 팀원 프로젝트 수행 중 팀장에게 보고하고 지시를 받음 팀장 프로젝트 계획을 작성하고 통제함 단점 팀장 중심의 팀 구성으로 팀장의 능력에 따라 프로젝트 성패가 좌우될 가능성이 크다. © 2008 Software Engineering

11 계층적 팀 구성 (1/2) 소개 구조 팀의 구성이 둘 이상의 단계로 나누어짐
프로젝트가 크고, 참여인원이 많을 때 많이 채택되는 방식 구조 (a) 조직 구성 (b) 의사 소통 경로 © 2008 Software Engineering

12 계층적 팀 구성 (2/2) 역할 소개 장점 각 그룹의 장(리더) 팀장
그룹원들을 책임지고 관리 팀장 그룹 리더들로부터 보고를 받고, 그룹 리더들과 의논하고 지시사항을 전달 장점 그룹원들은 그룹 리더들과, 그룹 리더들은 팀장과 의사소통을 하기 때문에 의사교환 경로를 줄일 수 있음 © 2008 Software Engineering

13 민주적 팀 구성 소개 구조 장/단점 (a) 조직 구성 (b) 의사 소통 경로
모든 팀원이 리더의 역할을 하고, 중요한 의사 결정은 팀원 모두가 참여 구조 장/단점 팀원의 사기와 작업 만족도를 높이고, 의사 결정시 많은 의견을 통한 결정을 할 수 있다는 장점 의사 교환 경로가 많아 의견의 합의점을 찾는데 시간이 걸릴 수 있음 (a) 조직 구성 (b) 의사 소통 경로 © 2008 Software Engineering

14 스케줄링(Scheduling)

15 스케줄링이란? 의미 프로젝트의 완성을 위해 수행되어야 할 작업을 나열한 후 연관 관계와 순서에 따라 기간 별로 나타내는 것 스케줄링 방식 WBS (Work Breakdown Structure) 프로젝트 중 수행되어야 하는 작업들을 파악 © 2008 Software Engineering

16 WBS (Work Breakdown Structure)
의미 프로젝트를 톱 다운(Top Down) 방식으로 세분화하여 프로젝트의 단위 작업에 대해 파악하는 기법 프로젝트의 목표를 달성하고 필요한 인도물(Deliverables)을 산출하기 위하여 프로젝트 팀이 수행할 작업을 인도물 중심으로 분할한 계층 구조 체계 (Deliverable-oriented hierarchical decomposition of the work) 표현 방식 프로젝트의 전체 범위를 구성하는 프로젝트 산출물 중심의 트리구조(Tree Structure)로 나타나는데, 단계(level)가 아래로 내려갈수록 프로젝트의 작업들이 점차적으로 상세히 정의 © 2008 Software Engineering

17 WBS 작성 예제 – 결혼식 준비 결혼식 준비 사전준비 장소 및 식사 손님초대 결혼식 진행 식후 행사 준비 회의
Level 1 결혼식 준비 Level 2 사전준비 장소 및 식사 손님초대 결혼식 진행 식후 행사 Level 3 준비 회의 예식장 장소섭외 손님리스트 작성 프로그램 작성 프로그램 작성 예식장 검토후 확인 주소록 작성 주례 및 사회 섭외 진행관련자 할당 피로연 장소섭외 청첩장 작성 진행관련자 할당 메뉴 검토후 확인 청첩장 발송 © 2008 Software Engineering

18 폭포수 생명 주기 기반의 WBS 예제 ... Work Package 개발 테스트 작업 소프트웨어 프로젝트 문서작업
시스템 요구분석 소프트웨어 설계 시스템 통합 테스트 사용자 매뉴얼 코딩 모듈 테스트 단위/기능 요구명세서 기능명세서1 기능명세서2 기능명세서3 기능명세서4 기능명세서5 기능설계서2 기능설계서3 기능설계서4 기능설계서5 구조 설계서 기능설계서1 블록설계서2 블록설계서3 블록설계서4 블록설계서5 블록설계서1 블록2 블록3 블록4 블록5 블록1 ... Work Package - WBS의 말단 노드를 말함 © 2008 Software Engineering

19 웹사이트 구축 WBS 예 (산출물 기준) 웹사이트 구축 분석 기획 화면설계 및 구현 요구사항명세서 프로젝트 계획서
DB상위설계서 기능설계 및 구현 통합테스트 테스트계획서 사이트 기획서 DB상세설계서 개발환경명세서 상위 스토리보드 설계서 디자인 이미지 검토결과서 소스코드 상세 스토리보드 설계서 통합테스트 결과보고서 시스템테스트 결과보고서 착수 개발 인수인계 및 오픈 사이트 관리 © 2008 Software Engineering

20 프로젝트 산정

21 산정 개념 프로젝트 수행에 필요한 규모(Size), 공수(Effort), 비용(Cost) 등을 정량적으로 예측하는 것 산정 방법 경험적 방법 프로젝트의 수량을 예측하기 위해서 노력과 시간에 대한 수식을 경험적으로 유도한 것 예: 델파이 기법(Delphi) 크기 중심 방법 LOC(Lines of Code : 프로그램 코드 라인 수)로 측정 예: LOC, COCOMO 기능 중심 방법 사용자 중심의 기능의 크기로 측정 예: 기능점수(Function Point)로 측정 © 2008 Software Engineering

22 델파이(Delphi) 기법 의미 산정 프로세스 경험적 산정 방법 전문가들의 의견이나 판단을 종합하여 예측하는 기법
전문가 의견 개진 (동일한 질문지) 설문조사 결과 상호 공유 (자신의 견해 수정) 설문결과 취합 결과 도출 필요한 만큼 반복 © 2008 Software Engineering

23 LOC(Lines Of Code) 의미 산정 프로세스 크기 중심적 산정 방법 프로그램 코드 라인의 수를 통해 산정
단계 1. 전체 프로그램을 모듈 별로 분할 단계 2. 모듈 별로 규모 추정 및 총 규모 계산 EV = (Vopt + 4 Vm + Vpess) / 6 Vopt= 낙관적 규모 Vm= 보통의 규모 Vpess= 비관적 규모 단계 3. 경험적 데이터를 이용한 개발 비용 및 개발 노력 추정 생산성 (LOC / Man-Month)을 이용 => 노력 추정 LOC당 비용 (α 원/ LOC) => 비용 추정 (α : 경험적 데이터로부터 산정함) © 2008 Software Engineering

24 [예] LOC 산정 (1/2) 쇼핑몰 시스템: 모듈 별로 분할 각 모듈 별로 규모 추정 모듈 1: 상품 관리 모듈
모듈 2: 상품 주문 모듈 모듈 3: 상품 주문 처리 모듈 모듈 4: 회원 관리 모듈 각 모듈 별로 규모 추정 모듈번호 낙관적 LOC (Vopt) 보통의 LOC (Vm) 비관적 LOC (Vpess) 추정 LOC (EV) 1 250 400 750 433 2 300 450 820 487 3 350 600 1,100 642 4 170 550 320 추정 LOC 합계 1,882 © 2008 Software Engineering

25 [예] LOC 산정 (2/2) 경험적 데이터를 이용한 개발 노력 및 개발 비용 추정 경험적 데이터 프로젝트 비용 개발 노력
생산성: 620 LOC / Man-Month LOC당 비용: 3,000원 / LOC 프로젝트 비용 1,882 LOC × 3,000 = 5,646,000원 개발 노력 1,882 LOC / 620 ≒ 3.0 M/M (Man-Month) © 2008 Software Engineering

26 COCOMO(Constructive Cost Model)
개념 Boehm이 제시한 LOC 기반의 경험적 산정 모델 경험적으로 추출된 상수와 추정된 LOC를 기반으로 개발 노력과 개발 기간을 산정하는 기법 수식 E = a × (KLOC) b D = c × (E) d * E (Effort): 개발 노력, D (Duration): 개발 기간, KLOC (Kilo Lines of Code(1000LOC)): 라인 수 프로젝트 유형별 상수 값(상관 계수 테이블) 기본형 비교적 작고 간단한 프로젝트 소수의 경험이 있는 팀이 까다롭지 않은 요구사항을 갖고 프로젝트 수행 중간형 중간 정도의 크기와 복잡도를 가짐 다양한 경험을 가진 팀이 약간 까다로운 요구사항을 갖고 프로젝트 수행 내장형 제한된 하드웨어, 소프트웨어와 운영조건을 갖고 프로젝트 수행 프로젝트 a b c d 기본형 2.4 1.05 2.5 0.38 중간형 3.0 1.12 0.35 내장형 3.6 1.20 0.32 © 2008 Software Engineering

27 [예] COCOMO 산정 개발 프로젝트 산정 쇼핑몰 시스템: 프로젝트 유형 중 “중간형”에 해당함
예상 규모: 2,103 LOC = 2.1 KLOC 산정 E = 3.0 ⅹ (KLOC)1.12 = 3.0 ⅹ (2.1)1.12 ≒ 6.9 M/M (Man-Month) D = 2.5 ⅹ (E)0.35 = 2.5 ⅹ (6.9)0.35 ≒ 4.9 M (Month) 프로젝트 a b c d 기본형 2.4 1.05 2.5 0.38 중간형 3.0 1.12 0.35 내장형 3.6 1.20 0.32 © 2008 Software Engineering

28 FP(Function Point)의 개요
의미 Software Metric to size an Information System based on the functionality that is perceived by the user of the information system, independent of the technology used to implement the information system 시스템을 구현한 기술에 독립적이고, 사용자에 의해 식별되는 기능에 기반하여 전체 시스템의 크기를 측정하는 척도 장점 개발에 사용된 기술, 개발 환경(개발 언어, 도구 등) 및 개발자의 능력에 독립적 프로젝트 초기에 규모 산정이 가능 단점 주관적인 자료를 바탕으로 하기 때문에 산정 값에 신뢰도가 떨어질 수 있음 출처: ISO © 2008 Software Engineering

29 FP의 측정 프로세스 출처: IFPUG 3. 데이터 기능 측정 5. 미조정 기능점수 결정 4. 트랜잭션 2. 측정 범위와
1. 측정 유형의 결정 2. 측정 범위와 어플리케이션 경계 식별 3. 데이터 기능 측정 4. 트랜잭션 6. 조정인자 5. 미조정 기능점수 결정 7. 조정 출처: IFPUG © 2008 Software Engineering

30 1. 측정 유형의 결정 개발 프로젝트(Development Project) 기능 점수 (DFP)
신규로 시작되는 시점부터 유지보수가 시작되기 전까지의 최초의 기능의 크기를 산정 개선 프로젝트(Enhancement Project) 기능 점수 (EFP) 기존 시스템의 변경 부분을 측정하는 것으로, 추가, 수정, 삭제한 기능 부분의 크기 측정 어플리케이션(Application) 기능 점수 (AFP) 시스템이 제공하는 현재 기능의 크기를 측정하는 것으로, 개발 프로젝트가 완료되거나 개선 프로젝트가 완료된 시점에 시스템이 제공하는 기능의 크기 측정 개발 시작 개발 완료 개선 시작 개선 완료 DFP 프로젝트 진행시간 EFP 1 개선 1 EFP 2 개선 2 AFP 1 AFP 2 AFP 3 © 2008 Software Engineering

31 2. 측정 범위와 어플리케이션 경계 식별 측정 범위 어플리케이션 경계
기능점수를 측정하는 대상이 되는 범위로, 하나 이상의 어플리케이션이 포함될 수 있음 어플리케이션 경계 측정 대상 어플리케이션과 다른 어플리케이션 및 사용자 사이의 경계 영화예매 어플리케이션 결제 처리 어플리케이션 경계 측정 범위 사용자 영화 정보 조회 영화 예매 정보 입력 영화 예매 시스템 영화정보 은행정보 은행 조회 결제 정보 출력 결제 정보 © 2008 Software Engineering

32 3. 데이터 기능 측정 (1/3) 사용자의 내 · 외부 데이터 요구사항을 충족시키기 위해 제공되는 기능을 측정 데이터 기능
내부 논리 파일 (ILF: Internal Logical Files) 측정 대상 어플리케이션 내부에서 유지되며, 사용자가 요구한 기능을 수행하기 위해 읽히거나 참조되는 데이터 그룹의 모음 (예) 영화 정보 외부 연계 파일 (EIF: External Interface Files) 측정 대상 어플리케이션 외부에서 유지되며, 사용자가 요구한 기능을 수행하기 위해 읽히거나 참조되는 데이터 그룹의 모음 (예) 은행 정보 영화예매 어플리케이션 결제 처리 어플리케이션 경계 영화정보 은행정보 영화제목 개봉날짜 등급 상영시간 줄거리 극장명 좌석번호 영화정보 ILF 은행 조회 운영시간 주소 은행명 은행 정보 EIF © 2008 Software Engineering

33 3. 데이터 기능 측정 (2/3) ILF와 EIF의 측정
레코드요소유형(RET: Record Element Type)과 데이터요소유형(DET: Data Element Type)의 개수에 따라 기능점수 크기가 결정 RET: ILF 또는 EIF 내에 존재하는 것으로, 하나의 정보를 구성하는 데이터베이스의 테이블과 같은 관련데이터의 그룹 (예) 영화 정보 테이블, 회원 정보 테이블 DET: RET를 구성하는 개별 데이터 (예) 영화 제목, 상영시간 등 영화예매 어플리케이션 결제 처리 어플리케이션 경계 영화정보 은행정보 영화제목 개봉날짜 등급 상영시간 줄거리 극장명 좌석번호 영화정보 ILF 은행 조회 운영시간 주소 은행명 은행 정보 EIF RET DET 영화정보 ILF 2개 (영화 테이블, 극장 테이블) 7개 (영화제목, 상영시간, 개봉날짜, 줄거리, 등급, 극장명, 좌석번호) 은행정보 EIF 1개 (은행 테이블) 3개 (은행명, 주소, 운영시간) * 표에서 테이블은 DB의 테이블 개념 © 2008 Software Engineering

34 ILF와 EIF의 측정 규칙 ILF 측정 규칙 EIF 측정 규칙
The group of data or control information is logical and user identifiable. The group of data is maintained through an elementary process within the application boundary being counted. EIF 측정 규칙 The group of data is referenced by, and external to, the application being counted. The group of data is not maintained by the application being counted. The group of data is maintained in an ILF of another application. © 2008 Software Engineering

35 RET와 DET의 측정 규칙 RET 측정 규칙 DET 측정 규칙
Count a RET for each optional or mandatory subgroup of the ILF or EIF. If there are not subgroups, count the ILF or EIF as one RET. DET 측정 규칙 Count a DET for each unique user recognizable, non-repeated field maintained in or retrieved from the ILF or EIF through the execution of an elementary process. When two applications maintain and/or reference the same ILF/EIF, but each maintains/references separate DETs, count only the DETs being used by each application to size the ILF/EIF. Count a DET for each piece of data required by the user to establish a relationship with another ILF or EIF. © 2008 Software Engineering

36 3. 데이터 기능 측정 (3/3) 미리 정의된 복잡도 와 기여도 Metric에 적용하여 ILF와 EIF의 값을 산정 예제 결과
DET 1 ~ 19 20 ~ 50 > 51 RET 1 Low Average 2 ~ 5 High > 5 복잡도 Low Average High ILF 7 10 15 EIF 5 복잡도 기여도 영화정보 ILF Low 7 은행정보 EIF 5 © 2008 Software Engineering

37 4. 트랜잭션 기능 측정 (1/4) 어플리케이션이 데이터를 처리하여 사용자에게 제공하는 기능의 크기를 측정 트랜잭션 기능
외부 입력 (EI: External Input) 어플리케이션 경계 외부의 사용자 또는 다른 어플리케이션으로부터  들어오는 데이터나 제어 정보를 이용하여 사용자의 요구를 처리하는 기능 예) 영화 예매를 요청한다. 외부 출력 (EO: External Output) 데이터나 제어 정보를 어플리케이션 경계 외부의 사용자 또는 다른 어플리케이션으로 내보내어 사용자의 요구를 처리하는 기능 계산 또는 수학 공식과 같은 처리 로직에 의한 파생 데이터가 발생 예) 영화 예매 결제 정보를 출력한다. 외부 조회 (EQ: External in Inquiry) 계산 또는 수학 공식과 같은 처리 로직을 포함하지 않으며, 파생 데이터도 발생하지 않음 예) 영화 정보를 조회한다. © 2008 Software Engineering

38 4. 트랜잭션 기능 측정 (2/4) 영화 예매 시스템 영화예매 어플리케이션 EQ 결제 처리 EO EI 측정 범위
어플리케이션 경계 측정 범위 사용자 영화 정보 조회 영화 예매 정보 입력 결제 정보 출력 영화 예매 시스템 EI 은행 조회 EQ 영화정보 은행정보 결제 정보 EO © 2008 Software Engineering

39 4. 트랜잭션 기능 측정 (3/4) EI, EO, EQ의 측정
참조파일유형(FTR: File Typed Referenced)과 데이터요소유형(DET: Data Element Type)의 개수에 따라 기능점수 크기가 결정 FTR: 트랜잭션 기능에 의해 유지되거나 참조되는 ILF 또는 참조되는 EIF (예) 영화정보, 은행정보 DET: 사용자가 식별 가능하고 비반복적인 유일한 필드 (예) 영화 제목, 전화번호 등 영화 선택 우리 생애 최고의 순간 무방비 도시 뜨거운 것이 좋아 마법에 걸린 사랑 어린 왕자 더 재킷 말할 수 없는 비밀 영화 예매 극장 선택 강남 씨네마 용산 CGV 아트레온 서울 극장 대한 극장 정동 극장 드림 씨네마 일 월 화 수 목 금 토 29 30 Jan 10: :30 15: :00 20: :00 상영시간 예매 취소 시간 선택 FTR DET 영화 예매 EI 1개 (영화 정보 ILF) 5개 (영화 제목, 극장 명, 상영 일자, 상영 시간, 처리결과메시지) © 2008 Software Engineering

40 EI 측정 규칙 EI 측정 규칙 The data or control information is received from outside the application boundary. At least one ILF is maintained if the data entering the boundary is not control information that alters the behavior of the system. For the identified process, one of the following three statements must apply. Processing logic is unique from the processing logic performed by other external inputs for the application. The set of data elements identified is different from the sets identified for other external inputs for the application. The ILFs or EIFs referenced are different from the files referenced by other external inputs in the application. © 2008 Software Engineering

41 EO 측정 규칙 EO 측정 규칙 The function sends data or control information external to the application boundary. For the identified process, one of the following three statements must apply. Processing logic is unique from the processing logic performed by other external outputs for the application. The set of data elements identified is different from the sets identified for other external outputs for the application. The ILFs or EIFs referenced are different from the files referenced by other external outputs in the application. For the identified process, one of the following rules must apply .for the elementary process to be counted as a unique external output. The processing logic of the elementary process contains at least one mathematical formula or calculation. The processing logic of the elementary process creates derived data. The processing logic of the elementary process maintains at least one ILF. The processing logic of the elementary process alters the behavior of the system. © 2008 Software Engineering

42 EQ 측정 규칙 EQ 측정 규칙 The function sends data or control information external to the application boundary. For the identified process, one of the following three statements must apply. Processing logic is unique from the processing logic performed by other external inquiries for the application. The set of data elements identified is different from the sets identified for other external inquiries for the application. The ILFs or EIFs referenced are different from the files referenced by other external inquiries in the application. For the identified process, one of the following rules must apply .for the elementary process to be counted as a unique external inquiry. The processing logic of the elementary process retrieves data or control information from an ILF or EIF. The processing logic of the elementary process does not contain a mathematical formula or calculation. The processing logic of the elementary process does not create derived data. The processing logic of the elementary process does not maintain an ILF. The processing logic of the elementary process does not alter the behavior of the system. © 2008 Software Engineering

43 EI에 관한 FTR, DET 측정 규칙 EI에 관한 FTR 측정 규칙 EI에 관한 DET 측정 규칙
Count one FTR for each ILF or EIF maintained during the processing of the EI. Count one FTR for each ILF or EIF read during the processing of the EI. Count only one FTR for each ILF that is both maintained and read during the processing of the EI. EI에 관한 DET 측정 규칙 Count one DET for each user recognizable, non-repeated field that enters or exits the application boundary and is required to complete the EI. Do not count fields that are retrieved or derived by the system and stored on an ILF during the elementary process if the fields did not cross the application boundary. Count one DET for the capability to send a system response message outside the application boundary to indicate an error occurred during processing, confirm that processing is complete or verify that processing should continue. Count one DET for the ability to specify an action to be taken even if there are multiple methods for invoking the same logical process. © 2008 Software Engineering

44 EO, EQ에 관한 FTR 측정 규칙 EO에 관한 FTR 측정 규칙 EQ에 관한 FTR 측정 규칙
Count one FTR for each ILF or EIF maintained during the processing of the EO. Count one FTR for each ILF or EIF read during the processing of the EO. Count only one FTR for each ILF that is both maintained and read during the processing of the EO. EQ에 관한 FTR 측정 규칙 Count one FTR for each ILF or EIF read during the processing of the EQ. © 2008 Software Engineering

45 EO, EQ가 공유하는 DET 측정 규칙 EO, EQ가 공유하는 DET 측정 규칙
Count one DET for each user recognizable, non-repeated field that enters the application boundary and is required to specify when, what and/or how the data is to be retrieved or generated by the elementary process. Count one DET for each user recognizable, non-repeated field that exits the boundary. Count one DET for the capability to send a system response message outside the application boundary to indicate an error occurred during processing, confirm that processing is complete or verify that processing should continue. Count one DET for the ability to specify an action to be taken even if there are multiple methods for invoking the same logical process. Do not count fields that are retrieved or derived by the system and stored on an ILF during the elementary process if the fields did not cross the application boundary. Do not count literals as DETs. Do not count paging variables or system-generated stamps. © 2008 Software Engineering

46 4. 트랜잭션 기능 측정 (4/4) 미리 정의된 복잡도 와 기여도 Metric에 적용하여 값을 산정 예제 결과
EI 복잡도와 기여도 Metric EO/EQ의 복잡도와 기여도 Metric 예제 결과 DET 1 ~ 4 5 ~ 15 > 16 FTR < 2 Low Average 2 High > 2 복잡도 Low Average High EI 3 4 6 DET 1 ~ 5 6 ~ 19 > 20 FTR < 2 Low Average 2 ~ 3 High > 3 복잡도 Low Average High EO 4 5 7 EQ 3 6 복잡도 기여도 영화 예매 EI Low 3 © 2008 Software Engineering

47 5. 미조정 기능점수(UFP: Unadjusted Function Point) 결정
소프트웨어 산정을 기능적인 관점에서 계산한 것으로 데이터 기능 점수와 트랜잭션 기능 점수의 합으로 결정 UFP = 데이터 기능 점수 + 트랜잭션 기능 점수 = (ILF + EIF) + (EI + EO + EQ) © 2008 Software Engineering

48 6. 조정 인자(VAF: Value Adjustment Factor) 결정
소프트웨어 산정은 기능의 크기 외에도 운영 환경 또는 성능 등에 영향을 받음 어플리케이션에 영향을 미치는 14개의 요인들을 일반 시스템 특성이라고 함 각 특성에 대한 대한 영향도 정도의 범위(DI, Degree of Influence)는 영향도 없음에서 영향도 강함까지, 0점에서 5점까지 표시 일반 시스템 특성 Data Communications (데이터통신) Distributed data processing (분산데이터처리) Performance (시스템 성능) Heavily used configuration (운영환경) Transaction rate (트랜잭션 비율) Online data entry (온라인 데이터 입력) End user efficiency (사용자의 효율성) Online update (온라인 갱신) Complex processing (처리 복잡도) Reusability (재사용성) Installation ease (설치 용이성) Operational ease (운영 용이성) Multiple sites (다중 설치성) Facilitate change (변경 용이성) VAF = (일반 시스템 특성의 총 영향도 합(TDI) * 0.01) © 2008 Software Engineering

49 일반적인 웹 기반 어플리케이션의 영향도 및 조정 인자
일반 시스템 특성 영향도 (DI) Data Communications (데이터통신) 4 or 5 Distributed data processing (분산데이터처리) 3 or 4 Performance (시스템 성능) Heavily used configuration (운영환경) 3 ~ 5 Transaction rate (트랜잭션 비율) 0 ~ 4 Online data entry (온라인 데이터 입력) 5 End user efficiency (사용자의 효율성) Online update (온라인 갱신) 3 (일반적인 GUI 어플리케이션 점수) Complex processing (처리 복잡도) 플랫폼과는 무관 Reusability (재사용성) Installation ease (설치 용이성) Operational ease (운영 용이성) Multiple sites (다중 설치성) Facilitate change (변경 용이성) 총 영향도 (TDI) 27 ~ 36 + α 조정인자 (VAF) 0.93 ~ α © 2008 Software Engineering

50 7. 조정기능점수(AFP: Adjusted Function Point) 결정
미조정 기능점수에 조정 인자를 반영한 기능 점수 값 AFP = UFP * VAF © 2008 Software Engineering

51 일정 계획

52 일정 계획 의미 표현 방법 WBS를 통해 파악된 단위 작업들을 산정된 기간 또는 비용 등에 기반하여 계획하는 활동 차트를 사용
장점 일정을 한 눈에 확인할 수 있음 역할 할당이나 병렬 작업 구성 등을 쉽게 표현 가능 종류 퍼트(PERT) 차트 간트(Gantt) 차트 © 2008 Software Engineering

53 퍼트 차트(PERT Chart) (1/2) 소개 표기법과 의미 장점
PERT: Program Evaluation and Review Technique 프로젝트를 구성하는 작업들 사이의 관계 및 흐름을 그래픽으로 표현 표기법과 의미 박스(또는 원): 작업이나 업무 선과 화살표: 각 작업간의 순서와 의존성을 표현 각 작업은 병행적으로 수행될 수 있음 장점 관리자는 프로젝트의 모든 작업들 간의 상호 의존성 및 프로젝트가 진행되는 다양한 경로 파악 가능 관리자는 프로젝트가 종료되는데 가장 적은 시간으로 퍼트 차트의 가장 긴 경로 예측 가능 © 2008 Software Engineering

54 퍼트 차트(PERT Chart) (2/2) 퍼트 차트 용어
ES(Earliest Start Time): 해당 단위 작업이 가장 빨리 시작할 수 있는 일자 EF(Earliest Finish Tme): 해당 단위 작업이 가장 빨리 종료할 수 있는 일자 LS(Latest Start): 해당 단위 작업이 가장 늦게 시작하는 일자 LF(Latest Finish): 해당 단위 작업이 가장 늦게 종료할 수 있는 일자 Du(Duration): ES에서 EF까지, LS에서 LF까지의 작업 기간 FT(Float Time): LS에서 ES 사이의 여유 기간 © 2008 Software Engineering

55 [예] 결혼식 준비 퍼트 차트 ES Du EF FT 단위작업 LS LF 2 5 7 예식장 장소섭외 7 1 8
단위 작업 기간 선행작업 준비회의 2 - 예식장 장소섭외 5 예식장 검토/확인 1 손님리스트 작성 피로연 장소섭외 예식장 검토/확인, A 경로 주요 경로(Critical Path) 2 5 7 예식장 장소섭외 7 1 8 예식장 검토 및 확인 8 1 9 피로연 장소섭외 2 준비회의 2 4 손님리스트작성 6 8 B 경로 © 2008 Software Engineering

56 간트 차트(Gantt Chart) 소개 표기법과 의미 장점 단점 Henry L. Gantt에 의해 제안됨
프로젝트의 일정, 예산 및 자원 계획 등을 목적으로 사용될 수 있는 프로젝트 제어 기법 표기법과 의미 시간의 순으로 되어 있는 캘린더에 프로젝트 시작 시간과 종료 시간을 막대 형태로 나타냄 왼쪽 열: 수행해야 할 작업들, 시작일과 완료일, 기간 표시 막대의 길이: 수행해야 하는 작업의 시간 장점 차트를 왼쪽에서 오른쪽으로 읽으면 작업 시작일과 종료일을 분명히 알 수 있음 현재 작업 상태, 늦어진 작업 현황, 앞으로 진행할 작업에 대해 쉽게 파악 가능 단점 퍼트 차트와 달리 작업간의 의존성을 보여주지는 않음 © 2008 Software Engineering

57 [예] 결혼식 준비 간트 차트 © 2008 Software Engineering

58 EVM (Earned Value Management)

59 프로젝트 통제란? 착 수 계 획 실 행 종 료 통 제 계획 vs. 실적 계획 변경
착 수 계 획 실 행 종 료 계획 vs. 실적 계획 변경 통 제 [PMBOK 2004][Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements. Project management is accomplished through the application and integration of the project management processes of initiating, planning, executing, monitoring and controlling, and closing.] 착수 새로운 프로젝트나 프로젝트 단계의 시작을 공식적으로 승인 받기 위해 진행할 프로세스들로 구성됨 계획 프로젝트 계획서를 작성 프로젝트가 수행해야 할 목표 및 범위를 달성하기 위해 필요한 행동 방침을 계획 실행 프로젝트 수행에 필요한 인력과 자원을 갖추고 프로젝트 계획을 시행 통제 프로젝트가 계획대로 잘 수행되고 있는가를 주기적으로 검토 프로젝트 목표를 달성하는 데 필요하면 시정 조치를 취할 수 있도록 함 종료 결과물의 인수를 공식화 함 계약의 의무를 수행했다고 판단되면 프로젝트를 종료 프로젝트가 계획대로 잘 수행되고 있는가를 주기적으로 검토 프로젝트 목표를 달성하는 데 필요하면 시정 조치를 취할 수 있도록 함 © 2008 Software Engineering

60 계획 vs. 실적 일정 비용 작업 성과 © 2008 Software Engineering

61 프로젝트 관리 현황 여러 프로젝트 중 70%는 일부의 프로젝트들은 거대 자금과 시간을 투자하고도 프로젝트를 완료하지 못함
비용 초과 일정 지연 일부의 프로젝트들은 거대 자금과 시간을 투자하고도 프로젝트를 완료하지 못함 출처: The Standish Group 그러므로, 프로젝트 통제를 위한 관리 방법이 중요함 © 2008 Software Engineering

62 EVM의 개요 의미 특징 프로젝트가 계획대로 잘 진행되고 있는지를 통제하기 위한 모니터링 관리 기법
프로젝트의 일정 상태, 비용 상태 그리고 완료된 작업량을 비용화하여 계획 대비 실적을 비교 및 평가함으로써 프로젝트의 성과와 진행률을 정량적으로 관리 특징 계획(Planed) 대비 실제수행(Actual)의 비교가 가능 프로젝트 진행 단계 중 특정 시점까지 완료된 작업량을 비용화하여 계획된 비용과 비교 평가하여 관리하는 방법 프로젝트가 계획대로 진행되고 있는가에 대한 성과측정(Performance Measurement)을 가능하게 하는 기법 비용과 시간을 모두 화폐단위(Money)로 통합하여 정량화함 프로젝트의 일정 상태, 비용 상태 그리고 작업에 대한 완료 상태를 모두 금액으로 환산하여 관리 하는 방법 © 2008 Software Engineering

63 EVM의 기본 용어 (1/2) BCWS (Budgeted Cost of Work Scheduled)
PV(Planned Value) 계획된 작업량의 계획된 비용 BCWP (Budgeted Cost of Work Performed) EV(Earned Value) 수행한 작업의 계획된 비용 ACWP (Actual Cost of Work Performed) AC(Actual Cost) 수행한 작업의 실제 비용 © 2008 Software Engineering

64 EVM의 기본 용어 (2/2) BAC (Budget at Completion)
BCWS의 합 전체 작업에 대한 계획된 비용 EAC (Estimate at Completion) ACWP + 남은 작업량에 대한 예측된 비용 전체 작업이 완료되는데 예측되는 실제 비용 EAC 1,000만원 비용 BAC $ $ $ $ $ $ $ 시간 © 2008 Software Engineering

65 SV (Schedule Variance)
개요 BCWP- BCWS 계획된 작업량과 실제 수행된 작업량의 차이 계획된 비용 기반이므로, 비용은 작업량에 따라 정비례함 마이너스 값은 일정 지연을 의미함 BC WS BC WP 계획된 비용 기반 (Budget based) 플러스(Plus)값: 계획보다 일정이 빠름을 의미 마이너스(Minus)값: 계획보다 일정이 느림을 의미 BCWP BCWS SV (￦) 30,000원 – 40,000원 = -10,000원(SV) 10,000원의 비용만큼 일정이 지연되었다. © 2008 Software Engineering

66 BC WP AC WP CV (Cost Variance) BCWP ACWP CV (￦) 개요 BCWP- ACWP
계획된 비용과 실제 비용의 차이 마이너스 값은 비용초과를 의미함 수행된 작업량 기반 (Performance based) 플러스(Plus)값: 계획보다 비용이 남음을 의미 마이너스(Minus)값: 계획보다 비용이 초과됨을 의미 BC WP AC WP BCWP ACWP CV (￦) 30,000원 - 50,000원 = -20,000원(CV) 20,000원의 비용이 초과되었다. © 2008 Software Engineering

67 SV와 CV 그래프 표현 출처: The University of New Mexico
© 2008 Software Engineering

68 성과 지표(Performance Indices)
SPI (Schedule Performance Index) SPI = BCWP / BCWS SPI < 1 이면 일정 지연을 의미 CPI (Cost Performance Index) CPI = BCWP / ACWP CPI<1 이면 비용 초과를 의미 출처: The University of New Mexico © 2008 Software Engineering

69 VAC (Variance at Completion)
플러스(Plus)값: 전체 작업을 완료할 때, 계획보다 비용이 남음을 의미 마이너스(Minus)값: 전체 작업을 완료할 때 계획보다 비용이 초과됨을 의미 B AC AC E BAC EAC VAC (￦) 100,000원 - 120,000원 = -20,000원(VAC) 전체작업이 완료될 때 20,000원의 비용이 초과할 것이다. EAC의 공식 ACWP + 남은 작업량에 대한 예측된 비용 ※ EAC = ACWP + ((BAC – BCWP)/CPI) © 2008 Software Engineering

70 VAC 그래프 표현 출처: The University of New Mexico
© 2008 Software Engineering

71 EVM 그래프 출처: The University of New Mexico 50,000 40,000 30,000 20,000
현재시점 완료일 50,000 40,000 EAC VAC 30,000 BAC 20,000 BCWS 10,000 ACWP BCWP SV CV 1월 2월 3월 4월 5월 6월 7월 출처: The University of New Mexico © 2008 Software Engineering

72 [예] EVM - 쇼핑몰 웹 사이트 개발 (1/4) 프로젝트 개요 [예제] 쇼핑몰 웹 사이트 개발 총 계약금: 9,000만원
소요 예정비용: 8,000만원 수익 예정비용: 1,000만원 총 개발 일정: 6개월 참여 인원: 8명 웹 기획자: 3명 웹 디자이너: 2명 웹 프로그래머: 3명 © 2008 Software Engineering

73 [예] EVM - 쇼핑몰 웹 사이트 개발 (2/4) 작업 별 현재 진행상태 작업요소 코드 M/D 비용(\) 전체 작업
Month 1 2 3 4 5 6 전체 작업 80,000,000 사이트기획 A 17 7,200,000 회원관리 B 12 4,000,000 판매 C 20 10,400,000 주문 D 배송 E 13 4,800,000 고객지원 F 검색 G 25 12,800,000 관리자모드 H 테스트/오픈 I 80,000,000 7,200,000 100% 4,000,000 100% 10,400,000 100% 10,400,000 40% 4,800,000 20% 24시간이 3일인 이유는 1일 = 8시간 일함 7,200,000 15% 12,800,000 3% 12,800,000 0% 10,400,000 0% 현재시점 © 2008 Software Engineering

74 [예] EVM - 쇼핑몰 웹 사이트 개발 (3/4) 프로젝트 진행 상태는 다음의 그래프와 같고, 현재 EVM 관련 지표의 측정시점에 대한 비용상태가 표와 같다고 가정하자. 현재시점의 비용상태 BCWS 45,760,000  BCWP 44,400,000 ACWP 50,000,000 © 2008 Software Engineering

75 [예] EVM - 쇼핑몰 웹 사이트 개발 (4/4) 측정된 결과 데이터 SV
= 44,400, ,760,000 = -1,360,000 일정이 1,360,000원 만큼 지연됨 CV = 44,400, ,000,000 = -5,600,000 비용이 5,600,000원 만큼 초과됨 CPI = BCWP/ACWP = 44,400,000/50,000,000 = 0.88 CPI값이 1보다 작으므로 비용이 초과되었음을 알 수 있음 EAC = ACWP+(BAC-BCWP) / CPI = 50,000,000 + (80,000, ,400,000) / 0.88 = 90,454,545원 프로젝트 완료 시점에 예측되는 총 소요비용은 90,454,545원으로 예측됨 VAC = BAC - EAC = 80,000, ,454,545 = -10,454,545원 프로젝트 완료 시점의 총 소요비용이 10,454,545원 만큼 계획보다 초과될 것이 예측됨 © 2008 Software Engineering

76 연습문제 (1/2) 프로젝트 계획 수립을 시작할 때 제일 먼저 해야 하는 작업을 기술하라.
프로젝트의 개발 비용 산정 시 결정에 영향을 주는 요소를 3가지 기술하라. 소프트웨어 개발 비용은 시스템 크기, 개발 기간, 신뢰도, 투입 인력들과 일정한 상관 관계가 있다. 개발 비용을 Y 축으로 하는 반비례 그래프를 그려본다면, X 축으로 어떤 요소가 가장 타당한지 기술하라. 두 명의 개발자가 5개월에 걸쳐 10,000라인의 코드를 개발하였을 때, 월별(Man Month) 생산성 측정을 위한 계산 방식은 어떻게 하는지, 식을 기술하라. LOC 기법에 의하여 예측된 총 라인수가 25,000라인일 경우 개발에 투입될 프로그래머의 수가 5명이고, 프로그래머들의 평균 생산성이 월당 500라인일 때, 개발에 소요되는 시간을 계산하라. © 2008 Software Engineering

77 연습문제 (2/2) 대표적인 소프트웨어 산정 모형(Estimation Model) 3가지를 기술하라.
기능점수(Function Point) 산정 방식의 7단계 프로세스를 기술하라. 일정 계획에 사용되는 대표적인 차트는 무엇이고, 이들에 대해서 기술하라. 프로젝트 통제 기법에 대표적인 EVM에 대해서 기술하라. EVM의 측정 지표와 성과 지표에는 무엇이 있는가? © 2008 Software Engineering

78 팀 프로젝트 7, 9주차

79 이번 주 할일 각 팀은 프로젝트 계획서를 작성하여 제출한다. © 2008 Software Engineering

80 다음 주 제출 문서 설계 문서를 작성하여 제출한다. © 2008 Software Engineering

81 Example > 이해를 돕기 위한 PMP시험문제 하나 발췌~ A project was estimated to cost $1.5 million and scheduled to last six months. After three months, the earned value analysis shows the following: EV = $650,000, PV = $750,000, AC = $800,000 What are the schedule and cost variances? <A>  SV= +$100,000 / CV= +$150,000 <B>  SV= +$150,000 / CV= -$100,000 <C>  SV= -$50,000 / CV= +$150,000 <D>  SV= -$100,000 / CV= -$150,000 © 2008 Software Engineering