프로젝트 계획서
참여자 모두가 프로젝트를 진행하면서 참조하는 프로젝트의 중심이 되는 문서
프로젝트 관리자는
- 프로젝트 태스크 파악
- 각 태스크를 수행하기 위해 필요한 노력 예측
- 인적 및 기타 자원을 각 태스크에 할당
- 일정 계획 수립
프로젝트 참여자의 검토를 거처 합의 하에 채택
프로젝트 진행 과정의 주기적 통제의 기본
프로젝트 계획서가 현실적으로 작성되어 전체 프로젝트 진행사항 파악이 용이해야 함
국제 표준 - IEEE 1058.1
규모 산정 : 프로젝트 수행에 필요한 규모(Size), 공수(Effort), 비용(Cost) 등을 정량적으로 예측하는 것
- 경험적 방법 : 프로젝트의 노력과 시간을 경험적 전문가들이 예측하는 방식 (가장 정확), 예: 델파이 기법(Delphi)
- 크기 중심 방법 : LOC (Lines of Code)로 측정, 예: LOC, COCOMO
- 기능 중심 방법 : 사용자 관점의 기능의 크기로 측정(소프트웨어 규모 산정 표준 기법), 예: 기능점수(Function Point)
(1) 델파이 기법
- 경험적 산정 방법으로 전문가들의 의견이나 판단을 종합하여 예측(인터뷰, 설문)
(2) LOC
단계 1: 전체 프로그램을 모둘 별로 분할
단계 2: 모듈 별로 규모 추정 및 규모 계산
단계 3: 경험적 데이터를 이용한 개발 비용 및 개발 노력 추정
Man-Month : 한 사람이 한 달간 할 수 있는 생산량 (한 사람이 한 달간 코드를 얼마나 생산할 수 있는가)
- 생산성(= 한 사람이 한 달간 몇 줄 생산) (LOC / Man-Month)을 이용 => 개발 노력(공수) 추정
- LOC당 비용(= 한 줄당 비용) ( α 원 / LOC) => 개발 비용 추정 ( α 원: 경험적 데이터로 추정)
예) 경험적 데이터를 이용한 개발 노력 및 개발 비용 추정
추정 프로젝트 규모 : 1,882 LOC
- 경험적 데이터
생산성 : 620 LOC / Man-Month
LOC당 비용 : 3,000원 / LOC
비용 추정 : 1,882 * 3,000원 = 5,646,000원
노력 추정 : 1,882 LOC / 620 = 3.0MM => 3사람*1달, 1사람*3달, 2사람*1.5달
(3) COCOMO (Constructive Cost Model)
- Bohem이 제시한 LOC 기반의 경험적 산정 모델
- 경험적으로 추출된 상수(동계 자료 기반)와 추정된 LOC를 기반으로 개발 노력과 개발 기간을 산정
E(Effort) = a * (KLOC) ^ b
D(Duration) = c * E ^ d
* 시스템 워딩이 들어가면 중간형
– E = 3.0 ⅹ (KLOC)1.12 = 3.0 ⅹ (2.1)1.12 ≒ 6.9 MM (Man-Month)
– D = 2.5 ⅹ (E)0.35 = 2.5 ⅹ (6.9)0.35 ≒ 4.9 M (Month)
위와 같은 경우, 1.4명이 필요 (E와 D 조합하면 몇 명 필요한지 나옴!)
스케줄링
수행되어야 하는 작업을 연관 관계와 순서에 따라 기간 별로 나타내는 것
WBS(Work Breakdown Structure)
- 프로젝트 중 수행되어야 하는 작업들을 파악(작업들이 뭐가 있는 지 최소 단위로 쪼개서 파악)
.퍼트(PERT) 차트 / 간트(Gantt) 차트
- 전반적인 일정을 한 눈에 확인 가능
- 역할 할당이나 병렬 작업 구성등을 쉽게 표현 가능
(1) WBS (Work Breakdown Structure)
- 프로젝트를 탑 다운 방식으로 세분화 하여 프로젝트의 단위 작업를 파악하는 기법
- 프로젝트 팀이 수행할 작업을 인도물(산출물) 중심으로 분할한 계층 구조
- 프로젝트 산출물 중심의 트리 구조(Tree Structure)
- 단계(Level)가 아래로 내려갈수록 프로젝트의 작업들이 점차적으로 상세하게 정의
- 어디까지 내려가야 하나? : 각 단계에서 산출물(인도물)이 나오면 거기서 stop해도 됨, 산출물이 나오는 level에서 stop
(2) 퍼트 차트(PERT Chart)
- Program Evaluation and Review Technique
작업들 사이의 관계 및 흐름을 그래픽으로 표현
- 박스(원) : 작업이나 업무
- 선과 화살표 : 각 작업간의 순서와 의존성
- 각 작업은 병행적으로 수행될 수 있음
- 장점 : 작업들 간의 상호 의존성 및 다양한 경로 파악 가능,
필요한 최소 소요기간은 퍼트 차트의 가장 긴 경로(임계 경로)를 통해 예측 가능
* Criticla Path(임계 경로) : 퍼트 차트의 가장 긴 경로
- 용어
– ES(Earliest Start Time): 해당 단위 작업이 가장 빨리 시작할 수 있는 일자
– EF(Earliest Finish Time): 해당 단위 작업이 가장 빨리 종료할 수 있는 일자
– LS(Latest Start Time): 해당 단위 작업이 가장 늦게 시작하는 일자
– LF(Latest Finish Time): 해당 단위 작업이 가장 늦게 종료할 수 있는 일자
– Du(Duration Time): ES에서 EF까지, LS에서 LF까지의 작업 기간
– FT(Float Time): LS에서 ES 사이의 여유 기간
CPM 네트워크 (작업들 간 우선순위, 의존성, Critical Path 파악 가능)
* 임계경로 상의 작업을 담당하는 사람들은 여유 시간이 없음
PERT : ES, LS, 여유시간등등 더 디테일하게 표현
CRM : 간단한 형태
(3) 간트 차트 (Gantt Chart)
- 시간 순으로 되어있는 캘린더에 시작 시간과 종료 시간을 막대 형태로 나타냄
- 장점 : 작업 시작.종료일을 분명히 알 수 있음, 현 작업 상태, 늦어진 작업, 앞으로 진행할 작업에 대해 쉽게 파악 가능
- 단점 : 작업간의 의존성을 보여주지는 않음
기능 점수 : 표준 규모 산정 기법
- 시스템을 구현한 기술에 독립적이고, 사용자에 의해 식별되는 기능에 기반하여 전체 시스템의 규모를 측정하는 척도
- IBM사의 Allan Albrecht에 의해 처음 개발
- 국제 기능 점수 사용자그룹 (IFPUG)
- 언어 상관x 플랫폼 상관x, 개발자 입장x (쓸모 있는 코드만 규모 산정에 포함되도록)
장점
- 기술, 환경, 개발자 능력에 독립적
- 요구사항만으로 측정 가능해 개발 초기에 산정 가능
- 개발은 물론 계획, 운영 전 단계에서 측정 가능
단점
- 측정에 비용과 시간 소요
- 정확한 측정이 어렵고, 알려지지 않은 기능과 복잡도 고려해야함
1. 측정 유형의 결정
개발 프로젝트 기능 점수 (DFP)
- 시작 시점부터 유지보수 시작 전까지의 최초 기능의 크기 측정
개선 프로젝트 기능 점수 (EFP)
- 기존 시스템의 변경 부분(추가, 수정, 삭제 기능 부분)의 크기 측정
- 유지보수 프로젝트에 적용
어플리케이션 기능 점수 (AFP)
- 운용중인 시스템의 기능 크기 측정
- 개발 프로젝트 완료되거나 개선 프로젝트가 완료된 시점에 기능의 크기 측정
- DFP와 개발 완료 시점의 AFP를 비교하여 얼마나 오차 있는 지 측정 가능 => 향후 작업에 대한 규모 예측에 활용
2. 측정 범위와 어플리케이션 경계 식별
측정 범위 : 기능 점수 측정 대상이 되는 범위, 하나 이상의 어플리케이션 포함 가능
어플리케이션 경계
- 측정 대상 어플리케이션과 다른 어플리케이션 및 사용자 사이의 경계
- 트랜잭션으로 처리된 데이터가 측정 대상 어플리케이션에 오가는 출입문
3. 데이터 기능 측정 : (ILF, EIF) 각각의 (RET, DET => 복잡도, 기여도)를 측정
내부 논리 파일(ILF: Internal Logical Files) :
측정 대상 어플리케이션 내부에서 유지되는 데이터 그룹의 모음,예) 영화 정보
측정 규칙 : 데이터가 어플리케이션 범위 내에서 기본 프로세스를 통해 유지되어야 함
데이터와 제어 정보가 논리적이고 사용자 관점에서 식별 가능함
외부 연계 파일(EIF: External Interface Files) :
측정 대상 어플리케이션 외부에서 유지되는 데이터 그룹의 모음. 예) 카드회사, 은행정보
측정 규칙 : 데이터가 어플리케이션 외부에 존재하며, 어플리케이션이 이를 참조함
데이터가 어플리케이션에 의해 유지되지 않으며, 외부 어플리케이션의 ILF에 의해 유지되어야 함
데이터와 제어 정보가 논리적이고 사용자 관점에서 식별 가능함
RET(Record Element Type, 레코드 요소 유형) :
하나의 정보를 구성하는 데이터베이스의 테이블과 같은 관련 데이터의 그룹
측정 규칙
1. ILF 또는 EIF의 서브 그룹을 RET로 카운팅
2. 서브 그룹이 존재하지 않으면, ILF 또는 EIF 자체(DB 자체)를 하나의 RET로 카운팅
DET(Data Element Type, 데이터 요소 유형) :
RET를 구성하는 개별 속성 (필드) 데이터
측정 규칙
(1). 기본 프로세스의 실행을 통해 유지되며, 사용자 식별 가능하고, 비반복적인 필드를 하나의 DET로 측정
여러 필드에 저장되어 있는 값은 하나의 DET로 카운팅
(반복될 경우 하나의 DET로)
(2). 두개의 어플리케이션이 동일 ILF/EIF를 유지 및 참조할때, 각각의 관련되는 필드만 각자의 DET로 카운팅
(중복될 경우 관련 필드만 각자 DET로)
예) 어플리케이션 A는 주소 정보로 시/도, 시/군/구, 읍/면/동, 번지를 별도로 식별하였고,
어플리케이션 B는 주소 정보 전체를 하나로 식별한 경우, A는 5개의 DET, B는 1개의 DET로 카운팅
예) 어플리케이션 X는 주민번호, 성명, 연락처, 주소, 우편번호를 유지,
어플리케이션 Z는 성명, 연락처, 주소만을 유지하는 경우 X는 5개의 DET, Z는 3개의 DET로 카운팅
(3). 타ILF나 EIF와 관계를 설정하기 위해 사용자가 요구하는 데이터는 하나의 DET로 간주
예) 동일 ILF 내의 직무명이 사원정보와 직무정보를 연결시키는 고리 역할을 할때, 하나의 DET로 카운팅
| ILF | ELF | |
| RET | 2 | 1 |
| DET | 7 | 3 |
| 복잡도 | Low | Low |
| 기여도 | 7 | 5 |
4. 트랜잭션(처리 동작의 최소 단위) 기능 측정 : 트랜잭션 각각의 (FTR, DET => 복잡도, 기여도)를 측정
데이터를 처리하여 사용자에게 제공하는 기능의 크기를 측정
EI (External Input)
어플리케이션 경계 외부에서 들어오는 데이터나 제어 정보를 이용하여 사용자의 요구를 처리하는 기능
측정 규칙: 입력되는 데이터가 시스템의 행위를 변경하며, 최소한 하나의 ILF가 유지됨
EO(External Output)
어플리케이션 경계 외부로 내보내어 사용자의 요구를 처리하는 기능으로 처리 로직에 의한 파생 데이터가 발생
측정 규칙: 처리 로직이 최소한 하나의 ILF를 유지하거나, 처리 로직이 시스템의 행위를 변경해야 함
EQ(External inQuiry)
어플리케이션 경계 외부로 내보내어 사용자의 요구를 처리하는 기능으로
처리 로직을 포함하지 않으며, 파생 데이터도 발생하지 않음
측정 규칙 : 수학 공식이나 계산을 포함하지 않으며, 파생 데이터를 생성하지 않음, 시스템의 행위를 변경하지 않음
FTR(File Typed Referenced): 트랜잭션 기능에 의해 유지되거나 참조되는 ILF 또는 참조되는 EIF (DB)
- EI, EO : 처리 동안 유지되고 읽혀지는 ILF 또는 EIF에 대해 각각 하나의 FTR로 카운팅
- EQ : 처리 동안 읽혀지는 ILF 또는 EIF에 대해 각각 하나의 FTR로 카운팅
DET(Data Element Type): 사용자가 식별 가능하고 비반복적인 유일한 필드
- (경계를 건너지 않는 필드는 카운팅하지 않음)
- (페이징 변수나 시스템 생성 스탬프는 카운팅 하지 않음) (개발자 관점이므로)
- (동일 로직에 대해 다수의 방법이 있을 경우, 하나의 DET로) 카운팅
- (에러 처리, 실행 완수 메세지는 각각 하나의 DET로 카운팅)
5. 미조정 기능점수 (UFP) 결정
UFP = 데이터 기능 점수 + 트랜잭션 기능 점수 = (ILF+ELF)+(EI+EO+EQ)
6. 조정 인자 (Value Adjustment Factor) 결정
소프트웨어 산정은 기능의 크기 외에도 운영 환경, 성능 등에 영향 받음
어플리케이션에 영향을 미치는 14개 요인 : 일반 시스템 특성
각 특성에 대한 영향도 정도 => 0(영향도 없음) ~ 5(영향도 강함)
VAF = (일반 시스템 특성의 총 영향도 합 = TDI:총 영향도)*0.01 + 0.65
- TDI range: 14 x (0 ~ 5) = 0 ~ 70
- VAF range: 0.65 ~ 1.35
7. 조정 기능점수 (AFP: Adjusted Function Point) 결정
AFP = UFP * VAF
소프트웨어 개발 비용
직접비 (인건비, 직접 경비) + 간접비(재경비:계약, 사무처리, 기술료:외부 기술 이용)
소프트웨어 개발 비용은 인건비 기준 (인건비 <= LOC, 기능점수, 델파이)
직접 경비 : 여비, 인쇄비, 이자, 재료비, 도구 사용료 등
프로젝트 통제
프로젝트가 계획대로 잘 수행되고 있는가를 주기적으로 검토
필요하면 시정 조치를 취할 수 있도록 함
계획 vs 성과 : 일정, 비용, 작업 성과
여러 프로젝트 중 70%는 비용 초과, 일정 지연
Earned Value Management(EVM)
- 비용, 일정, 작업 성과를 하나의 그래프로 관리
- 프로젝트가 계획대로 잘 진행되고 있는 지를 통제하기 위한 모니터링 관리 기법
- 프로젝트의 일정 상태, 비용 상태 그리고 완료된 작업량을 비용화하여
계획 대비 실적을 비교 및 평가함으로써 프로젝트의 성과와 진행률을 정량적으로 관리
- 프로젝트의 일정, 비용 그리고 완료를 모두 금액(화폐단위)으로 환산 통합하여 정량화
- 특정 시점까지 완료된 작업량을 비용화하여, 계획된 비용과 비교 평가
• 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) => 비용
- 수행한 작업의 실제 비용
• BAC (Budget at Completion)
- BCWS의 합
- 전체 작업의 계획된 비용
• EAC (Estimate at Completion)
- EAC = ACWP + (BAC-BCWP) / CPI
- 전체 작업의 완료되는데 예측되는 실제 비용
• VAC (Variance at Completion)
- VAC = BAC - EAC
- (+): 전체 작업을 완료할 때 계획보다 비용이 남음
- (-): 전체 작업을 완료할 때 계획보다 비용이 초과됨
SV (Schedule Variance)
- BCWP- BCWS
- 계획된 비용 기반 (Budget based)
- (+): 계획보다 일정이 빠름을 의미
- (-): 계획보다 일정이 느림을 의미 (일정 지연)
CV (Cost Variance)
- BCWP - ACWP
- 수행된 작업량 기반 (Performed based)
- (+): 계획보다 비용이 남음을 의미
- (-): 계획보다 비용이 초과됨을 의미
성과 지표 (Performance Indices)
• SPI (Schedule Performance Index)
- SPI = BCWP / BCWS
- SPI < 1 이면 일정 지연을 의미
• CPI (Cost Performance Index)
- CPI = BCWP / ACWP
- CPI < 1 이면 비용 초과를 의미
예제 #1 - 쇼핑몰 웹 사이트 개발
소요 예정 비용: 8000만원
현재 시점의 비용 상태
- BCWS: 4576만원
- BCWP: 4440만원
- ACWP: 5000만원
답 #1
SV = -136만: 일정이 136만 만큼 지연됨
CV = -560만: 비용이 560만 만큼 초과됨
CPI = 0.88: 1보다 작으므로 비용이 초과됨
EAC = 90,454,545원: 프로젝트 완료 시점 예측되는 총 소요 비용
VAC = -10,454,545원: 프로젝트 완료 시점에 총 소요비용이 계획보다 초과될 것
예제 #2
답 #2
ACWP: 270만
BCWP: 240만
BCWS: 300만
CPI: 0.89
CV: -30만
SPI: 0.8
SV: -60만
EAC = 416만
VAC = -46만