공수 및 비용산정

소프트웨어 비용산정 개념

비용은 소프트웨어 규모를 소요공수와 투입자원 및 소요기간으로 파악하여 실행 가능한 계획을 수립하기 위한 목적으로 산정한다.

1. 비용산정의 의의

단위작업공수(비용)를 통한 총 공수(총비용)을 WBS에 근거하여 산출하면 계약의 근거로 활용한다.

(1) 낮게 산정 시: 품질문제 발생, 납기문제, 개발자 부담 가중

(2) 높게 산정 시: 예산낭비, 일의 효율성 저하Specific: 구체적

2. 비용산정 결과: 노력(인월, E), MM(Man-Month), PM(Person Month)

소프트웨어를 한 달 간 개발하는데 소요되는 총 인원수 또는 한 사람을 기준으로 몇 개월 에 개발할 수 있는 양인가를 의미하며, 개발 기간을 간접적으로 측정할 수 있는 근거가 된다.

3. 개발 비용 산정시 고려 사항

(1) 프로젝트 요소

어떤 소프트웨어를 개발할 것인가에 따라 비용이 달라질 수 있다. 프로젝트 요소에는 제품의 복잡도, 시스템의 크기, 요구되는 신뢰도 등이 있다.

(가) 제품의 복잡도 : 소프트웨어의 종류(응용·유틸리티·시스템 소프트웨어 등)에 따라 달라지는 문제의 난이도를 의미한다.

(나) 시스템의 크기 : 소프트웨어의 규모(대형 · 소형 소프트웨어)에 따라 입출력 양식수 등 개발할 시스템의 규모를 의미한다.

(다) 요구되는 신뢰도 : 신뢰도는 프로그램이 일정한 기간 내에 주어진 조건하에서 필요한 기능을 수행하는 정도로 정확성, 견고성, 완전성, 일관성등을 의미한다.

(2) 자원 요소

소프트웨어 개발에 필요한 각종 자원들의 투자 정도에 따라 비용이 달라질 수 있다. 자원 요소에는 인적 자원, 하드웨어 자원, 소프트웨어 자원 등이 있다.

(가) 인적 자원 : 관리자, 개발자의 능력 혹은 자질

(나) 하드웨어 자원 : 개발 장비나 워드프로세서, 프린터와 같은 보조 장비

(다) 소프트웨어 자원 : 언어 분석기, 문서화 도구, 요구 분석기 등과 같은 개발 지 원 도구

(3) 생산성 요소

소프트웨어 생산성에 영향을 주는 요소에는 개발자의 능력, 경험 및 주어진 개발 기간 등이 있다.

(가) 개발자의 능력 : 전문 분야에 대한 지식, 유사 분야에 대한 경험, 응용 분야에 대한 이해도, 책임감, 창의력 등

(나) 개발 기간 : 소프트웨어를 개발하는 기간

규모 산정 방법

1. 상/하향식 산정방법

(1) 하향식 산정방법

(가) 경험적 단언(시스템 이해한 후), 개발자 합의(인력, 시스템 크기, 예산)

소프트웨어 개발 기술에 관한 경험이 많은 전문가의 판단에 따라 비용을 산출하는 방법으로 지식을 갖춘 2명 이상의 전문가에게 의뢰하는 방식이다. 장점으로는 간편하고, 신뢰감을 줄 수 있지만, 단점으로는 낙관적 결과를 만들어내 기도 하고, 비과학적(기술적 요인을 간과하기 쉬움)으로 객관성 부여가 어려울 수 있다. 즉, 개인적 차이가 크게 날 수 있기 때문이다. 사소한 문제로 인한 결정이나 그룹 내의 한 사람에 의한 독단으로 가면 문제가 발생할 가능성이 있다.

(나) 전문가 감정과 델파이 방식 이용

회의의 부작용을 방지하면서 전문가의 의견 일치를 얻기 위하여 1948년 랜드사 (Rand Co.)에서 개발한 방법으로 전문가의 판단 방법의 단점을 보완한 방법이다. 전문가들이 편견이나 분위기에 지배 받지 않도록 조정자(coordinator)를 필요로 한다. 델파이식 비용 산정 방법의 진행과정은 다음과 같다.

1) 조정자가 시스템 정의서와 비용 산출 양식을 전문가들에게 제공

2) 조정자는 전문가들이 비용 산출에 관한 토의를 위한 회의를 소집

3) 전문가들은 익명으로 각자의 산정 작업을 완료

4) 조정자는 그룹 산정과 개인 산정에 관한 내용을 요약하여 제시

5) 조정자는 산정내용의 차이가 많을 때, 그 문제에 초점을 맞추어 회의를 소집

6) 전문가들은 다시 익명으로 산정 작업을 실시 의견의 일치를 이룰 때까지 이 과정을 반복한다

(2) 상향식 산정방법

서브 시스템의 개발비를 산정한 후에 합산하여 전체 시스템의 비용을 산정하는 방법 으로 하향식 방법의 비과학성을 보완한 것이다. 개발할 시스템을 작업분류구조(WBS)로 정의하고, 각 구성요소에 대한 산정을 독립적으로 실시한 후 이를 합산하는 방식이다. 프로젝트를 위한 소 작업에 소요되는 기간을 구하고, 여기에 투입되어야 할 인력과 투 입 인력의 참여도를 곱하여 최종 인건비를 계산한다.

(가) 업무분류구조 정의, 각 구성요소에 대한 독립적 산정, 집계

(나) LOC 기법, 개발 단계별 인원수 기법 이용

2. 양적 규모 산정방법

(LOC 방식) 소스 라인 수에 근거한 규모산정 방식으로 LOC의 값은 쉽게 측정할 수 있고. 많은 측정 모델이 LOC를 사용한다는 것이 장점인 반면, 언어에 따라 크기가 가변적이며 기준이 모 호하여 코딩 표준이 필요하다는 것이 단점이다

(1) LOC 기법

LOC 기법(원시 코드 라인 수)은 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법이다.

(가) 측정이 용이, 이해가 쉬워 가장 많이 사용된다.

(나) 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정한다.

(다) 예측치

(단, A: 낙관치, B: 비관치, M: 중간치(기대치))

- 비관치 : 가장 많이 측정된 코드 라인 수

- 낙관치 : 가장 적게 측정된 코드 라인 수

- 기대치 : 측정된 모든 코드 라인 수의 평균

(라) 산정 공식

- 노력 (M/M) = 개발 기간 X 투입인원

- 개발 비용 = 노력 X 단위 비용 (1인당 월평균 인건비)

- 개발 기간 = 노력(MM) / 투입 인원 - 생산성 = LOC /노력(MM)

(마) 예제

LOC 기법에 의하여 예측된 총 라인 수가 30,000라인, 개발에 참여할 프로그래머가 5명, 프로그래머들의 평균 생산성이 월간 300라인일 때 개발에 소요되는 기간은?

- 노력(인월) = LOC/1인당 월평균 생산 코드 라인 수 = 30,000/300 = 100명

- 개발 기간 = 노력(인월)/투입 인원 = 100/5 = 20개월

(2) COCOMO((COnstructive COst MOdel) 모델

Boehm에 의해 비즈니스, 산업계, 정부, SW하우스 등에서 엄선한 63종류의 프로젝트 데이터에 기초하여 작성된 경험적인 소프트웨어 비용 견적모델로 COCOMO 모델 의의 는 가장 이해하기 쉬운 실험적 모델이다.

 

(가) 특징

- 개발할 소프트웨어의 규모(LOC)를 예측한 후 이를 소프트웨어 종류에 따라 다르 게 책정되는 비용 산정 방정식 (공식)에 대입하여 비용을 산정한다.

- 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적 에 널리 통용되고 있다.

- 같은 규모의 프로그램이라도 그 성격에 따라 비용이 다르게 산정된다.

- 비용 산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man-Month)으로 나타난다

 

(나) COCOMO 모형의 종류

COCOMO는 비용 산정 단계 및 적용 변수의 구체화 정도에 따라 기본(Basic), 중간 (Intermediate), 발전(Detailed)형으로 구분할 수 있다.

1) 기본(Basic)형 COCOMO

기본형 COCOMO는 소프트웨어의 크기(생산 코드 라인 수)와 개발 유형만을 이 용하여 비용을 산정하는 모형이다.

KDSI(Kilo Delivered Source Instruction): 전체 라인 수를 1,000라인 단위로 묶 은 것으로 KLOC(Kilo LOC)와 같은 의미이다

 

2) 중간(Intermediate)형 COCOMO

중간형 COCOMO는 기본형 COCOMO의 공식을 토대로 사용하나, 다음 4가지 특성의 15가지 요인에 의해 비용을 산정하는 모형이다.

- 제품의 특성 : 요구되는 신뢰도, 데이터베이스 크기, 제품의 복잡도

- 컴퓨터의 특성 : 수행 시간의 제한, 기억장소의 제한, 가상 기계의 안정성, Turn Around Time

- 개발 요원의 특성 : 분석가의 능력, 개발 분야의 경험, 가상 기계의 경험, 프 로그래머의 능력, 프로그래밍 언어의 경험

- 프로젝트 특성 : 소프트웨어 도구의 이용, 프로젝트 개발 일정, 최신 프로그래 밍 기법의 이용

- 산정 공식

장점은 비교적 정확한 모델이며 소프트웨어 개발비 견적에 유연성 부여한다는 점이다. 그러나 단점으로는 소프트웨어 제품을 하나의 개체로 보고 승수들을 전 체적으로 적용해야 하는데 대부분의 대형 시스템은 서로 상이한 서브시스템으 로 구성되고, 서로 적용되어야 하는 개발 유형이 다를 수 있다. 또한 일부분은 Organic mode이고, 일부분은 Embedded mode인 경우도 있다. 일부분에 대해서 는 신뢰도가 매우 높아야 하고, 일부분에 대해서는 신뢰도가 낮아도 되는 경우 도 있기 때문이다

 

3. 양과 질을 고려한 산정방법

소프트웨어 특성을 이용하여 간접적으로 규모와 복잡도를 산정하는 방식

(1) 기능점수 (Function Point)

정보처리 규모와 기술의 복잡도 요인에 의하여 소프트웨어 규모 산정방법으로 소프트 웨어의 양과 질을 동시에 고려한 방식이다. 최종사용자 입장에서 소프트웨어 규모를 견적하는 방식으로 프로젝트 완료 후 생산성 평가목적으로 개발 되었으나 사전 예측 모델로 이용하고 있다. 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능을 점수를 산출하여 총 기능 점수와 영향도를 이용 하여 기능 점수(FP)를 구한 후 이를 이용해서 비용을 산정하는 기법이다

(2) 소프트웨어 과학 (Software Science)

- 소프트웨어 규모, 난이도에 대한 척도를 이용하여 개발소요공수 예측모형제시

- 계산공식

소프트웨어 규모: (N1+N2) * log2(n1+n2)

난이도 = (n1/n2) * (N2/n2)

소요공수 = a * 규모 * 난이도

N1: 사용된 연산자 종류 수

N2: 사용된 피연산자 종류 수

n1: 연산자의 총사용량 (중복 카운트 합)

n2: 피연산자의 총사용량 (중복 카운트 합)