기능점수(FP)

카테고리 없음 2020. 5. 29. 15:15

I. MM ( Man Month )

1. S/W 개발비 산정 방법

산정방법

특징

산정 방법

기능점수(FP) 방식

기준 LOC(Line Of Code) 방식 산출물을 대체

소프트웨어 개발 규모와 기능 점수당 단가를 곱하여 소프트웨어 개발비를 산정

( 기능점수 * 가능점수 단가 * 보정계수 ) + 직접경비 + 이윤

투입공수 방식

과거 유사 소프트웨어 개발 사업의 투입인력 정도를 기초로 한 경험적 판단에 의한 사업대가 산정 방식

기능 점수 방식의 적용이 곤란한 특정 사업유형에 한하여 적용 가능

( 투입인력수 * 투입기간 * 기술자등급별단가 ) + 제경비 + 기술료 + 직접경비

기능점수 (Function Point) 의 정의

기능점수(Function Point)는 소프트웨어의 양과 질을 동시에 고려한 소프트웨어 규모산정 방식의 일종으로
정보처리규모와 기능적 복잡도에 의해 소프트웨어 규모를 사용자의 관점에서 기술적요소는 배제하고
측정하는 방식
기능점수 (Function Point) 의 특징

- 최종사용자 입장에서 소프트웨어의 규모를 견적하는 값임
- 프로젝트 완료 후 생산성 평가를 위해 개발되었으나 사전에 개발소요공수를 예측하는 모델로도 사용가능.
- 개발환경과 기술에 무관하게 측정가능하고 사용자의 요구에 따라 시스템 기능 설계시 개발 중에도 측정 가능함.
- 생산성과 품질 척도로도 활용 가능.

개발 프로젝트 기능점수(DFP)
- DFP = (UFP + CFP) * VAF
- UFP: 데이터의 컨버전에 의해 포함되는 기능 점수
- CFP: 변환 기능에 대한 미조정 기능 점수
- VAF: 개발 프로젝트에 대한 조정인자
개선 프로젝트 기능점수(EFP)
- EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB)
- ADD: 개선 프로젝트에 의해 추가된 기능들의 미조정된 기능 점수
- CHGA: 개선 프로젝트에 의해 수정된 기능들의 미조정된 기능 점수
- CFP: 데이터의 컨버전에 의해 포함된 기능 점수
- VAFA: 개선 프로젝트 이후의 애플리케이션의 값 조정 인자
- DEL: 개선 프로젝트에 의해 삭제된 기능의 미조정된 기능 점수
- VAFB: 개선 프로젝트 이전의 애플리케이션의 값 조정 인자

2. 시스템 규모 산정의 전제

원천 적재(L0), 데이터 통합 영역(L1), 요약 영역(L2), 시각화 영역으로 Application 경계를 구분하여 FP Counting 을 수행함

기능점수(Function Point) 산출방법

https://blog.naver.com/PostView.nhn?blogId=santalsm&logNo=220584982840

★ [2-6] 기능점수(Function Point) 산출방법에 대하여 설명하고, 간이법을 적용하여 아래의 이벤트(Eve

★ [2-6] 기능점수(Function Point) 산출방법에 대하여 설명하고, 간이법을 적용하여 아래의 이벤트(Eve...

blog.naver.com

SW 기능점수산정표에서 FP유형(EI, EO, EQ, ILF, EIF) - 블로그

https://m.blog.naver.com/PostView.nhn?blogId=solro98&logNo=221387823192&proxyReferer=https:%2F%2Fwww.google.com%2F

SW 기능점수산정표에서 FP유형(EI, EO, EQ, ILF, EIF)별 단위프로세스명 쉽게 작성하는 법

안녕하세요?일하기 좋은날이에요~! 복덩이 파랑입니다.SW대가를 산정하는 방법중에 기능점수산정법(F...

blog.naver.com

비용산정 방법

KMooc에 공개 되어 있는 '쉽게 배우는 소프트웨어 공학' 강의 내용을 정리한 것입니다.(강의: 공주대학교 컴퓨터공학부 김치수 교수)

또한, https://terms.naver.com/list.nhn?cid=58528&categoryId=58528를 확인하시면, '쉽게 배우는 소프트웨어 공학' 책 또한 공개되어있으니 참고하여주시면 감사하겠습니다.

1.top-down 산정 기법

과거의 유사 경험을 바탕으로 회의를 통해 산정하는 비과학적인 기법
전문가 판단 기법
- who : 경험이 많은 전무가가 개발 비용 산정
- when : 짧은 시간에 개발비를 산정하거나 입찰에 응해야하는 경우 많이 사용
- 단점 :
- 수학적 계산 방법보다 경험에만 의존할 경우 부정확할 수 있음
- 경험 해본 프로젝트와 유사하다고 생각하여 과소 평가할 우려 있음
델파이 기법
- 전문가의 경험을 중요시 하여 비용 산정 -> 전문가 판단 기법과 공통점
- 전문가들의 편견이나 분위기에 영향을 받지 않도록 조정자를 둠 -> 전문가 판단 기법과 차이점

2. bottom-up 산정 기법

세부 작업 단위 별로 비용 산정 -> 전체 비용 합산
LOC 기법
- 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 중간치 측정 -> 예측지 산정
개발 단계별 노력
- 소프트웨어 개발 생명 주기의 각 단계별 (인/월수, M/M)로 노력을 산정

source code line 수(LOC) 기법

비관/낙관/중간치 측정 -> 예측치 계산 -> 비용 산정(노력, 개발비용, 생산성)
낙관치 : 한 모듈의 라인 수를 가장 적게 생각할 때의 예상 라인 수(가중치 1부여)
비관치 : 한 모듈의 라인 수를 가장 많게 생각할 때의 예상 라인 수(가중치 1부여)
중간치 : 한 모듈의 라인 수를 보통이라고 생각할 때의 예상 라인 수(가중치 4부여)
추정LOC : (낙관치 + (4*중간치) + 비관치) / 6

LOC 비용산정 공식

노력(인/월수, M/M)
- (참여 인원/월) * 개발 기간
- 추정 LOC / 1인당 월평균 생산 코드 라인 수
개발 비용
- (m/m) * 단위비용(1인당 월 평균 인건비)
개발기간 : (m/m) / 참여인원
생산성 : LOC / (m/m)

개발 단계별 노력(m/m)기법

LOC : 개발하려는 SW의 총 코드 라인 수를 예측하여 구현단계에 대한 m/m을 산정
실제 SW 개발 : 코딩 뿐 아니라 require analysis, design 등의 단계에서도 인력과 자원이 많이 필요
따라서 LOC를 보완한 것이 개발 단계별 노력 기법!
- m/m을 SDLC(소프트웨어 개발 생명 주기)의 각 단계에 적용하여 단계별로 산정
- 코딩만 대상으로 산정하는 LOC보다 더 정확

수학적 산정 기법

상향식 비용 산정 기법
COCOMO
- SW의 규모(LOC)예측 후 SW조류에 따라 각 비용 산정 공식에 대입
F/P(Fuction Point) <- 정부에서 산정하는 기법!
- 기능 점수를 구한 후 이를 이용해 비용 산정

COCOMO(COnstructuve COst MOdel)방법

완성될 SW의 크기(LOC)를 추정 하고 이를 준비된 식에 대입하여 MM 예측
- 개발 비용 산정 시 source code 크기(라인수)에 중심을 둠 -> 라인수 많으면 개발 비용이 많이 듦
개발 비용 계산시 고려 사항
- 프로그램 유형(난이도)에 따른 가중치
- 네 가지 특성에 따른 15가지 분류(가중치)
cocomo 개발 절치
- 1.프로그램 유형에 따른 가중치 반영
- 2.15가지의 비용승수 요소에 따른 보정 계수 반영
- 3.총 개발 기간 산정

COCOMO 프로그램 유형에 따른 가중치 반영

단순형(organnic) 프로젝트
- 복잡도와 난이도가 비교적 높지 않은 업무용 소프트웨어
- 크기가 중소규모 정도, 50KDSI 미만
중간형(semi-detached) 프로젝트
- 일반 업무용 SW보다 복잡하고 규모가 더 큰 소프트웨어
- 크기가 300KDSI 미만 (OS, DBMS 등)
내장형(embedded) 프로젝트
- 자동화 기기나 전자 제품과 같은 하드웨어와 밀접한 관련 있는 SW
- 300KDSI

COCOMO 15가지의 비용승수 요소에 따른 보정 계수 반영

노력 조정 수치(EAF:Effort Adjustment Factor)
- 필요한 각 항목별 승수 값을 모두 곱한 값

COCOMO 2 방법

단계별 예측 후 인건비 산정에 반영

3.기능점수법

F/P 방법

사용자 관점에서 개발하려는 소프트웨어의 기능을 정량화하여 개발 비용 산정에 활용
- 소프트웨어 기능의 크기를 측정하는 단위
- SW 기능 복잡도를 상대적 점수로 표현
- 입출력, DB table, interface, 조회가 많은 사무용 소프트웨어 유용
- SW 개발 비용 산정, 유지보수 비 산정, 개발에 필요한 자원 산정시 사용

SW 기능 분류

데이터 기능
- 내부 논리 파일(ILF: Internal Logical File)
- 외부 연계 파일(EIF: External Input)
트랜잭션 기능
- 외부 입력(EI: External Input)
- 외부 출력(EO: External Output)
- 외부 조회(EQ: External inQuiry)

정규 기능 점수법

file 내의 record 단위까지 알아야 함
설계 단계 이후에 사용하면 유용
기능 도출 후 각 기능의 유형별 복잡도를 구해 기능 점수 산정

4.간이기능점수법

file 내의 record 단위까지 몰라도 가능함
기획 및 발주 단계에서 사용하면 유용
SW 기능을 도출한 후 각 기능에 평균 복잡도를 적용해 기능 점수 산정(평균 가중치가 매년 정해진다)

장점

사용자의 요구사항만으로 기능을 추출하여 측정
객관적인 요구사항만으로 측정
모든 개발 단계에서 사용

단점

높은 분석 능력 필요
기능 점수 전문가 필요
내부 로직 위주의 SW에는 다소 부적합
개발 규모 측정에 적합

사용이유

정규 기능 점수법 사용시 각 기능의 복잡도와 가중치 도출 필요
분석/설계 단계에나 기능의 속성까지 상세히 도출 가능
계획 단계의 예산 수립시 정규 기능 점수법은 사용이 어려움
유형별 복잡도 대신에 평균 복잡도 가중치 사용

가중치

일반복잡도 가중치 : ILF, EIF, EI, EO, EQ의 가중치를 필요시마다 계산해 사용
평균 복잡도 가중치 : 과거 FP(function point)산정 결과를 분석하여 복잡도를 계산한 가중치의 평균값
- 사용이유 : 예산 수립시 기능 점수 산정할 수 있는 자료 부족
- 사용 효과 : 복잡도 계산 과정 생략으로 비용산정이 쉽고 빠름
- 사용 용도 : 정규 기능 점수법 산정한 결과의 검증 시 사용
간이 시능 점수법 : 정규 기능 점수법 산정한 결과의 검증 시 사용
따라서, 간이기능 점수법은 프로젝트 초기단계에서 각 기능의 정확한 요소를 모를 경우 평균 복잡도 가중치를 사용하여 SW기능의 크기 측정

산정절차

ISO 14143

측정 유형 결정

개발 프로젝트 기능 점수(개발 규모 측정)
- 프로젝트가 완료되어 최초 설치 했을 때의 기능 크기 산정
- 프로젝트에서 사용자를 위해 제공된 모든 기능 측정
개선 프로젝트 기능 점수(변경 규모 측정)
- 사용중인 SW에 변경 발생시 변경된 부분의 기능 측정
- 완료된 프로젝트에서 추가/수정/삭제된 부분만 그 크기 측정
Application 기능 점수(응용 규모 측정)
- 현재 운영중인 application의 기능 측정
- 개발프로젝트 기능 점수 + 개선프로젝트의 기능 점수

측정 범위와 application 경계 식별

측정 범위에 포함될 요소(subsystem)의 식별
- 측정 범위 : 기능 점수를 측정하고자 하는 대상
- 측정 대상 : 몇 개의 application도 포함 가능. 개발하고자 하는 전체 SW(예 : 대학의 종합 정보 시스템). SW의 일부 시스템(예: 종합정보시스템의 학사관리에서 성적관리)
application 경계
- 금번 기능 점수 계산 대상과 제외 대상을 분리하여 경계를 지음
- 예: 개발 대상 - 학사관리, 예외대상 - 인사,회계관리
application 경계 주의사항
- 사용자 관점(학사, 인사, 회계...)으로 함
- 개발자 관점은 안됨(client/server ...)
- 적당한 크기
- 큰 경우 : 인사/회계/학사관리 - 기능 점수가 과소 산출 가능성 높음
- 작은 경우 : 학적 / 수업 / 교과 관리 - 기능 점수 과대 산출 가능성 높음

데이터 기능 점수 계산

데이터 FP 계산 = {(내부 논리파일(ILF)개수 * 평균 복잡도) + (외부 연계파일(ELF) 개수 * 평균복잡도)}
다만, 평균 복잡도는 이미 결정되어있음
데이터 기능 점수 = {(ILF * 7.5) + (EIF * 5.4)}
- 7.5 : 내부 논리 파일의 평균 복잡도
- 5.4 : 외부 연계 파일의 평균 복잡도
사용자 된점에서 본 기능 점수 5가지 유형

내부 논리 파일(ILF: Internal Logical File)
- 금번 프로젝트에서 생성하여 관리하는 데이터
- 예: 대학 정보시스템 DB안에 있는 Table
- 사용자가 등록/수정/삭제/조회를 하기 위한 대상
- DB에 존재하는 데이터 모임(DB의 정보)
- DB 정보 : FP 측정 대상으로 application내부에서 file로 유지
- DB table, 시스템 내부에서 다루는 file, class등
- application에 존재하는 데이터를 논리적으로 모아놓은것
외부연계파일(EIF: External Interface File)
- 금번 프로젝트에서 생성하지 않고 참조만 하는 데이터
- 예: 대학정보시스템에서 은행 DB안에 있는 '학생 등록금 정보'
- 측정대상 애플리케이션(대학정보시스템)에서는 참조만 하고 다른 애플리케이션(은행)에서 유지되는 파일

트랜잭션(transaction)기능 계산

트랜잭션 기능
- 입력, 출력, 조회
트랜잭션 기능 측정
- 외부입력, 외부출력, 외부조회의 횟수를 세는 것
트랜잭션 FP = {외부입력, 외부출력, 외부조회}의 개수 * 각각의 평균복잡도(가중치)
EI(external input)
- DB에 데이터를 등록하거나, 수정 삭제하는것 (학생 정보 등록,수정,삭제)
EO(external output)
- 계산하는 logic을 거쳐 데이터나 제어 정보를 사용자에세 보여주는 기능.
- 수학적 계산 logic이 하나 이상 존재하며 그에 따른 파생 데이터도 존재
- 학생학점 조회
EQ(external inquiry)
- logic이 필요없고 DB에 존재하는 데이터를 찾아 그대로 표시만 해주는 기능
- 학생 주소 검색, 학생 정보 조회
트랜잭션 기능 점수 = {(EI개수 * 4.0) + (EO개수 * 5.2) + (EQ개수 * 3.9)}
- 4.0 : 외부입력의 평균 복잡도
- 5.2 : 외부출력의 평균 복잡도
- 3.9 : 외부조회의 평균 복잡도

미조정 기능 점수(UFP : Unadjusted Function Point) 계산

UFP = data FP +. transaction FP
단순히 기능적인 요구사항에 대해서만 계산
여러가지 특성에 대한 고려를 하지 않음

보정 전 개발원가 계산

보정 전 개발 원가 = 미조정 기능점수 * 기능 점수당 단가
- 기능 점수당 단가 : 519,203원(출처:SW사업대가산정 가이드)
소프트웨어 개발 전체에 대한 기능 점수
단계별 기능 점수 가중치
- 분석, 설계, 구현, 테스트를 구분하여 별도의 사업으로 진행할 때 사용
- SW 개발 단계별 기능 점수 가중치

보정 후 기능 점수 계산

보정이 필요한 이유
- 기능 점수당 단가 519,203원은 복잡도가 보통일 때의 값
- 현실에서의 다양한 규모, 에플리케이션 유형, 개발언어, 사용자요구의 품질 및 특성에 따라 보정 필요
규모 보정 계수
- 규모에 따라 값을 보정
- 복잡도 증가 -> 생산성 하락 -> 보정 계수를 높임
- 기능 점수에 따라 달라짐
- FP < 300 규모 보정 계수 = 0.65
- FP >= 300 규모 보정 계수 = 공식 사용
애플리케이션 유형 보정 개수
- SW 유형에 따라 복잡도가 달라 생산성도 달라지는 것을 보정
- 복잡도 증가 = 개발 노력 증가
- 단순 정보처리용 < 통신제어용 < 과학 기술용
언어 보정 계수
- 언어에 따라 생산정도 달라지므로 개발 언어에 따른 보정 계수 적용
품질/특성 보정 계수
보정후 개발 원가 = 보정 전 개발 원가 * (규모보정계수 * 애플리케이션 보정계수 * 언어보정계수 * 품질특성 보정계수)

ABOUT ME

하쿠나 마타타 하쿠나 마타타