프로젝트 관리 및 생명주기 모형
02. 비용 측정
1) 비용 측정 요소
1. 직접 측정 요소
- 수치, 양, 크기처럼 직접적으로 측정이 가능한 요소
- 노력(인월), 비용, 라인 수(LOC), 오류 수, 투입 인원, 처리 속도, 문서 수 등이 있음
2. 간접 측정 요소
- 비교 대상이 있어야 측정이 가능한 요소
- 생산성, 품질, 기능 점수(FP), 문서화 비율, 효율성, 신뢰도, 유지보수성 등이 있음
2) 인월(MM : Man Month, PM : Person Month, 노력)
- 한 사람이 1개월 동안 작업할 양
- 24인월이면 1명이 24개월 동안 작업할 양이며, 24명이 1개월에 작업할 양
- 비용 측정 단위로 가장 많이 사용되는 요소
3) 비용 측정 원칙
1. 소프트웨어 비용 측정을 최대한 지연시킨다.
- 비용 측정의 실패는 프로젝트 전체의 실패
- 가능한 최대한 늦춰서 측정해야 실패 위험이 감소
2. 분해 기술을 이용한다.
- 개발할 소프트웨어를 기능별로 분리한 뒤 모아서 전체 비용을 측정해야 실패 위험이 감소
3. 실험적 비용 측정 모델을 이용한다.
- 이미 개발되었던 소프트웨어의 비용을 참고로 하여 측정
4. 자동화 도구를 이용한다.
- SLIM과 같은 비용 측정 프로그램을 이용하여 비용을 측정
4) 개발 비용과 개발 기간의 상관관계
- 개발 기간이 짧아질수록 개발 지용은 증가하고, 개발 기간이 증가하면 개발 비용이 감사
(반비례 그래프)
5) 간접 측정 평가 공식
생산성 = LOC / 인월
개발 기간 = 인월 / 개발 인원
개발 비용 = 인월 * 단위 비용(1인당 측정 금액)6) 비용 측정 방법론의 분류
1. 하향식
- 전체 비용을 측정한 후 기능이나 단계별 비용으로 분리하는 방법
2. 상향식
- 기능이나 단계별로 비용을 측정한 후 전체 비용을 측정하는 방법
7) 전문가 측정
- 소프트웨어 개발 비용을 전문적으로 측정하는 사람에게 의뢰하는 방법으로 신속하게 비용 결정이 되지만 전문가의 편견이 문제가 될 수 있음
8) 델파이(Delphi) 측정
- 중재자는 여러 전문가에게 개발할 소프트웨어에 대하여 설명
- 전문가들은 자신이 측정한 비용을 중재자에게 제출
- 중재자는 전문가들의 비용 측정 결과를 익명으로 공개
- 2, 3을 반복하면서 평균치의 비용을 최종 비용으로 결정
9) LOC(Line Of Code) 측정
- 소프트웨어를 기능별로 세분화
- 입력 기능, 처리 기능, 출력 기능으로 세분화한 기능의 라인 수를 예측
- 프로그램 개발에 경험을 가진 사람들이 예측한 라인 수 중 가장 적은 라인 수는 날관치, 많은 라인 수는 비관치, 평균은 기대치로 측정
- 측정된 라인 수를 공식에 적용하여 예측치를 계산
예측치 = (낙관치 + (4 * 기대치) + 비관치) / 6
- 예측치를 통해 라인당 비용을 측정해도 되고, 경험적인 방법으로 예측치의 인월을 산출하여도 됨
10) 단계별 인월(Effort per Task 기법)
- LOC 측정의 단점을 보완한 방식
- LOC 측정은 라인 수로만 측정되기 때문에 단계별 중요도가 무시됨
- 단계별 중요도를 인월로 가중치를 부여한 후 측정
- 예를 들어 입력 기능을 측정할 때 요구분석 단계에서의 작업이 구현 단계에서 하는 작업의 역할이나 중요도와 다르기 때문에 가중치를 인월로 부여하여 측정
- 전체 인월 합계는 단위 비용(월급)을 곱하여 계산
11) Walston 측정
- 미국의 60개 개발업체에서 이미 개발한 소프트웨어의 자료를 수집하여 통계적 공식을 만듦
- MM(인월) = 5.2 * [KDSI]0.91
- TDEV(개발기간) = 2.47 * [MM]0.35
- KDSI는 KLOC(전체 라인 수)에서 공백 라인, 주석, 라이브러리 등을 제외한 실제 수행되는 명령어 라인 수
- Walston 공식은 소프트웨어의 규모와 난이도에 상관없이 적용하기 떄문에 오차가 많음
- Walston 공식의 단점을 보완하여 COCOMO 단체에서는 소프트웨어의 규모와 난이도를 고려하여 3가지 형태로 분류
12) COCOMO 모형(Basic COCOMO)
1. 유기형(Organic)
- 기관 내부에서 개발된 중소 규모의 소프트웨어로 일괄 처리나 과학기술 계산용, 비즈니스 자료 처리용으로 5만 라인 이하의 소프트웨어를 평가하는 유형
- MM(인월) = 2.4 * [KDSI]1.05
- TDEV(개발기간) = 2.5 * [MM]0.38
2. 준 분리형(Semi-Detached)
- 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만 라인 이하의 소프트웨어를 평가하는 유형
- MM(인월) = 3.0 * [KDSI]1.12
- TDEV(개발기간) = 2.5 * [MM]0.35
3. 내재형(Embedded)
- 초대형 규모(제한 X)의 트랜잭션 시스템이나 운영체제 등의 소프트웨어를 평가하는 유형
- MM(인월) = 3.6 * [KDSI]1.20
- TDEV(개발기간) = 2.5 * [MM]0.32
13) Putnam 모형
- 대형 프로젝트에서 이용되는 기법
- 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도 곡선으로 그려짐
- 개발 기간이 연장될수록 프로젝트 적용 인원의 노력이 감소하므로 대형 프로젝트의 노력 분포 산정에 용이함
- Putnam 모형을 기초로 해서 만든 자동화 추정 도구는 SLIM
- SLIM은 총인월(MM), 개발 기간 등의 비용 측정값을 입력하면 소프트웨어 비용 산출을 자동으로 출력
- Putnam 모형 공식
- MM = LOC3 / ([개발 기술 지수]3 * [개발 기간]4)
- LOC = [개발 기술 지수] [MM] [개발 기간]
- 개발 기술 지수는 임의로 부여할 수 있는 값으로 예를 들면, 최악 환경은 12000, 보통 환경은 8000, 최상 환경은 5000 정도로 적용하면 됨
14) 기능 점수(Function Point) 모형
1. 기능 점수 모형의 개념
- 기능 점수는 논리적 설계 관점에서 사용자(고객)가 요구하고 인도받는 기능량을 정량적으로 산적하는 방식으로 소프트웨어 기능 규모 산정하는 소프트웨어 규모 산정 방법
- 기능 점수는 소프트웨어의 양과 질을 동시에 고려한 소트프웨어 규모 산정 방식의 일종으로 정보처리 규모와 기능적 복잡도에 의해 소프트웨어 규모를 사용자의 관점에서 기술적 요소는 배제하고 측정하는 방식
- 물리적인 파일이나 테이블 또는 프로그램 모듈 수를 산정하는 것이 아니라, 사용자 관점의 논리적 사용자의 기능 요구사항을 산정하는 것
- 산정 기준이 모두 규칙으로 정의되어 있어 비용 산정 결과의 일관성과 정확성을 확보할 수 있음
- 국제 표준 소프트웨어 규모 산정 방법으로 애플리케이션에 적용되는 방법이나 기술과 무관하게 사용자의 기능적 요구사항을 기준으로 산정하는 방법
2. 기능 점수 모형과 LOC 측정의 비교
| 구분 | 기능 점수 | LOC 측정 |
|---|---|---|
| 적용 시점 | 전체 생명주기 | 구현 이후 |
| 고객과의 소통 | 좋음 | 나쁨 |
| 관점 | 고객 관점 논리적 | 개발자 관점 물리적 |
| 표준 | 국제 표준(ISO/IEC 14143) | 없음 |
3. 기능 점수의 비용 산정 요소
- 입력 유형의 수 : 형식이 다른 입력 양식의 수, 입력 파일
- 출력 유형의 수 : 형식이 다른 출력 양식의 수, 출력 보고서
- 사용자 명령어 수 : 데이터 구조 변경을 위한 명령이 아니라 프로그램을 실행하는 명령어 수, 사용자 질의 수
- 데이터 파일의 수 : 시스템에 의해 생성되는 내부 파일의 수
- 인터페이스의 수 : 외부 프로그램과의 연계되는 수
