비용산정방법

비용산정방법

1.     문제의 정의

-      문제 정의

: 소프트웨어 개발의 첫 작업

: 무엇을 개발할 것인지 명확히 정의

: 개발 범위를 결정

è  프로젝트의 초기 타당성과 초기 계획을 작성할 수 있는 기초로 활용된다

 

-      문제 정의를 위한 필요 사항

: 개발하고자 하는 영역의 배경 지식 필요

: 문제를 파악하기 위해 현재 운영 중인 시스템을 사용해본다

: 실무 담당자와 면담하여 자료를 수집한 후 면밀히 분석

 

2.     타당성 분석

-      경제적 타당성 ( Economic Feasibility )

: 경영자 = 투자 효율성 ( Cost Benefit Analysis ) 에 관심

: 분석가 = 투자 대비 효과 검토 후 경영자에게 정확한 정보 제공

: 시장 분석을 통한 시장성 ( Marketability ) 확인

è  개발 여부 판단

 

 

-      기술적 타당성 ( Technical Feasibility )

: 현재의 기술로 사용자가 요구하는 기능을 구현할 수 있는지 검토

: 하드웨어 성능이 개발에 지장은 없는지 검토

: 개발자의 기술력에 문제가 없는지 검토

 

-      법적 타당성 ( Legal Feasibility )

: 개발용 소프트웨어와 도구의 사용이 법적으로 문제가 없는지 검토

: 지적 소유권과 프로그램 보호법이 강화되었으므로 법적인 문제 꼭 검토

 

3.     개발 비용 산정

-      개발비 산정의 어려움

ㄱ.   소프트웨어 개발 비용 예측할 때

: 가전제품 생산이나 건축 공사와 달리 사람(개발자)이 중심

: 개발자의 능력에 따른 생산성의 차이 = 기간과 품질에 영향

: 다양한 개발 프로세스로 인한 표준화/자동화의 어려움 = 다양한 생산성과 품질

è  명확한 개발비 산출의 어려움

 

-      SW 개발 비용에 영향을 주는 요소

ㄱ.   프로그램 자질

: 초급 프로그래머와 고급 프로그래머의 생산성 차이가 큼

è  프로그램의 자질 : 개발 비용에 영향을 줌

 

ㄴ.   소프트웨어 복잡도

: 브룩스의 법칙 = 애플리케이션 개발 < 유틸리티 개발 < 시스템 프로그램 개발

è  소프트웨어 복잡도 : 개발 비용에 영향을 미침

 

ㄷ.   소프트웨어 크기

: 참여 인력 증가, 개발 기간 길어짐, 복잡도 커짐

è  소프트웨어 규모 : 개발 비용에 영향을 미침

 

ㄹ.   가용 시간

: 관리자들의 잘못된 생각 : 인력/자원 증가는 개발 기간 단축

: 보헴 = 정상적인 계획에서 최대 75%가 줄일 수 있는 한계

 

ㅁ.   요구되는 신뢰도 수준

: 높은 신뢰도의 소프트웨어 개발 = 개발 비용의 증가

 

ㅂ.   기술 수준

: 고급언어 사용 = 저급 언어의 사용보다 5~10배의 생산성 증가

 

 

4.     비용 산정 기법 1 = 하향식 산정 기법

-      전문가 판단 기법

: 경험이 많은 전문가가 개발 비용을 산정 = 신뢰성 높음

: 짧은 시간에 개발비를 산정하거나 입찰에 응해야 하는 경우 많이 사용

: 단점 = 수학적 계산 방법보다 경험에만 의존할 경우 부정확할 수 있다.

 

-      전문가 판단 기법을 보완한 방법 ( 델파이 기법 )

:

 

5.     비용 산정 기법 2 = 상향식 산정 기법

-      상향식 산정 기법

: 세부 작업 단위별로 비용 산정후 전체 비용 합산

: 단점 = 수학적 계산 방법보다 경험에만 의존할 경우 부정확할 수 있음

 

-      원시 코드 라인 수 기법

: 원시 코드 라인 수의 비관치, 낙관치, 중간치를 측정 후 예측치를 구해 비용 산정

: 낙관적 = 한 모듈의 라인 수를 가장 적게 생각할 때의 예상 라인 수 ( 가중치 1 )

: 비관적 = 한 모듈의 라인 수를 가장 많게 생각할 때의 예상 라인 수 ( 가중치 4 )

: 보통 = 한 모듈의 라인 수를 보통이라고 생각할 때의 예상 라인 수 ( 가중치 1 )

: 추정 LOC = ( 낙관치 + (4X중간치) + 비관치 ) / 6

: 노력(인/월수 M/M) = (참여 인원/월) * 개발기간 = 추정 LOC / 1인당 월 평균 생산 코드 라인 수

: 개발 비용 = ( M/M ) * 단위 비용 (1인당 월 평균 인건비)

: 개발 기간 = ( M/M ) / 참여 인원

: 생산성 = LOC / (M/M)

 

-      개발 단계별 노력(Effort per task) 기법

: 생명주기의 각 단계별로 노력을 산정

ㄱ.   LOC

: 개발하려는 소프트웨어의 총 코드 라인 수를 예측하여 구현 단계에 대한 M/M을 산정

 

ㄴ.   실제 소프트웨어 개발

: 코딩뿐 아니라 요구 분석, 설계 등의 단계에서도 인력과 자원이 많이 필요

 

ㄷ.   개발 단계별 노력 기법 ( LOC 보완 )

: M/M을 소프트웨어 개발 생명주기의 각 단계에 적용하여 단계별로 산정

: 장점 = 코딩만 대상으로 산정하는 LOC 보다 더 정확

 

6.     비용 산정 기법 3 = 수학적 산정 기법

-      상향식 비용 산정 기법

-      경험적 추정 기법 또는 실험적 추정 기법

-      COCOMO 방법

: SW 규모 예측한 후 SW 종류에 따라 각 비용 산정 공식에 대입하여 비용 산정

: 라인 수 중심의 개발비 산정

: 개발비 산정 시 고려 사항

= 프로그램 유형에 따른 가중치

= PM = a X (KDSI) b승

 

ㄱ.   가중치 반영하기

è  개발 인건비의 초기 예측 값 산출 방법

è  단순형 ( PM ) = 2.4 X (KDSI) 1.06승

è  중간형 ( PM ) = 3.0 X (KDSI) 1.12승

è  내장형 ( PM ) = 3.6 X (KDSI) 1.20승

è  PM = Person/Month : 소프트웨어 개발에 필요한 인력 (인원/월)

è  KDSI = Kilo Delivered Source instruction : 소프트웨어의 최종 원시 코드 라인 수

: 유형별 M/M

: 단순형 < 중간형 < 내장형

 

ㄴ.   보정 계수 반영 하기

: “만일 개발하려는 소프트웨어의 KDSI가 60이고, 소프트웨어는 중간형이며, 노력 조정 수치가 2.04라면 노력(E)은 몇인가?

è  PM = 3.0 X (KDSI) 1.12승 X EAF = 3.0 X (60) 1.12승 X 2.04 = 600.179

: “만일 개발하려는 소프트웨어의 KDSI가 60이고, 소프트웨어는 중간형이며, 노력 조정 수치가 2.04라면 노력= 600.179이다 이 때 총 개발 기간은?

è  TDEV = 2.5X(PM)0.35승 = 2.5 X (600.179) 0.35승 = 23.461

 

ㄷ.   총 개발 기간 산정하기

-      Putnam 방법

: 소프트웨어 생명주기의 전 과정에 사용될 노력의 분포를 가정  

 

-      기능 점수 ( FP ) 방법

: 기능 점수를 구한 후 이를 이용해 비용 산정

ㄱ.   산정 근거

: 기능의 수 = 라인 수와 무관하게 기능이 많으면 규모도 크고 복잡도도 높다고 판단

: 사용자관점에서 소프트웨어의 기능 정량화 = 개발 비용 산정

ㄴ.   기능 점수

: 소프트웨어 기능의 크기를 측정하는 단위

= 소프트웨어의 기능이 얼마나 복잡한가를 상대적인 점수로 표현하는 것

ㄷ.   용도

: 개발 시 비용 산정

: 유지보수 비용 산정

: 개발 시 필요한 자원 산정

ㄹ.   특징

: 소프트웨어 규모를 측정하는 방법

: 기능적 요구 사항이 중심이 되는 측정 방법

: 소프트웨어의 요구 사항 복잡도를 측정

: 구현 관점 아닌 사용자 관점의 요구 기능을 정량적으로 산정

: 측정의 일관성 유지를 위해 개발 기술, 개발 방법, 품질 수준 등은 고려하지 않음

: 소프트웨어 개발에 사용되는 언어와 무관

: 소프트웨어 개발 생명주기의 전체 단계에서 사용 가능

ㅁ.   정규 기능 점수 법

: 설계 단계 이후에 사용하면 유용

ㅂ.   간이 기능 점수 법

: 기획 및 발주 단계에서 사용

: 데이터 기능 점수 = { ( 내부 논리 파일개수 X 7.5 ) + (외부 연계 파일개수 X 5.4 ) }

: 트랜잭션 기능 점수 = { ( 외부 입력 개수 X 4.0 ) + (외부 출력 개수  X 5.2) + ( 외부 조회 개수 X 3.9 ) }

: 외부 입력 = 데이터베이스에 등록 or 수정 or 삭제

: 외부 출력 = 계산하는 로직을 거쳐 사용자에게 보여주기

: 외부 조회 = DB에 존재하는 데이터를 찾아 그대로 표시해 주는 기능

ㅅ.   장점

: 사용자의 요구 사항만으로 기능을 추출하여 측정 ( 실제 구현 방법과 무관 )

: 객관적인 요구 사항만으로 측정 ( 개발 방법이나 개발 팀과 무관 )

: 모든 개발 단계에서 사용 ( 계획 단계뿐 아니라, 분석, 설계, 구현 단계에서도 가능)

ㅇ.   단점

: 높은 분석 능력 필요

: 기능 점수 전문가 필요

: 내부 로직 위주의 소프트웨어에는 다소 부적합

: 개발 규모 측정에 적합

 

-      미조정 기능 점수 ( UFP )

: 데이터 기능 점수 + 트랜잭션 기능 점수

: 단순히 기능적인 요구 사항에 대해서만 계산

: 여러 가지 특성에 대한 고려를 하지 않음

 

-      보정 후 개발 원가

: 보정 전 개발 원가 X ( 규모 보정 계수 X 애플리케이션 보정 계수 X 언어 보정 계수 X 품질.특성 보정 계수 )

Ex)

보정 전 개발 원가 = 기능 점수의 합 X 519.203

보정 계수 = 규모 보정 ( 0.65 ) , 애플리케이션 유형 보정 ( 1.0 ) , 언어 보정(0.8), 품질.특성 보정 (1.0)

보정 후 개발 원가 : 보정 전 개발 원가 X ( 0.65 X 1.0 X 0.8 X 1.0 )

 

7.     일정 계획

-      작업 분할 구조도 ( WBS : work breakdown structure )

: 프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화하는 작업

: 프로젝트 구성 요소들을 계층 구조로 분류

: 프로젝트의 전체 범위 정의

 

-      작업 패키지 ( Work Package )

 

: 계층 구조에서 최하위에 있는 항목

 

-      PERT/CPM

: WBS의 작업 순서, 소요 기간 등을 네트워크 형태의 그래프로 표현한 후 어떤 작업이 중요한지, 또 일정에 여유가 있는 작업은 어떤 것인지 찾아내 중점 관리를 해야 하는 작업을 명확히 하는데 사용

 

8.     위험 분석

-      프로젝트 수행 시 발생할 수 있는 위험 요소

: 개발자의 이직 , 요구 사항 변경 , 발주사의 재정적 어려움, 예상을 빗나간 투입 인력, 개발 기간 부족, 개발비 초과