출처: https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=lugenzhe&logNo=90108056587
□ 필요성
지식경제부 고시로 규정하고 있는 소프트웨어사업 대가의 기준은 국가기관 등이 정보전략계획 수립, 소프트웨어 개발, 소프트웨어 재개발, 데이터베이스구축, 시스템운용환경구축, 소프트웨어 유지보수 등의 정보화사업을 추진함에 있어 정보통신기술의 발전 및 사회적 여건변화에 유연하게 대처하고, 소프트웨어 산업과의 선순환적 구조를 가질 수 있도록 소프트웨어사업에 대한 예산수립, 사업발주, 계약 시 적정원가계산 등을 산정하기 위한 기준을 제공하는 것을 목적으로 하고 있습니다.
소프트웨어사업 대가의 기준은 1989년 제정된 이후 국제 표준의 소프트웨어 규모산정 기준인 기능점수를 도입하는 등 정보기술 발전과 사업환경 변화에 따라 수차례 개정되어 합리적인 비용산정의 근거를 확보해 오고 있습니다.
소프트웨어사업 대가의 기준을 통하여, 소프트웨어 규모산정의 정확성과 일관성을 높임으로써 국내 정보화사업의 품질을 향상시키고 제값주기 환경을 지속 정착시켜 소프트웨어 산업의 경쟁력을 제고하는 효과를 거둘 수 있을 것으로 기대합니다.
□ 개정경과
1) 1987년 12월 4일 법률 제 3984호로 [소프트웨어개발촉진법] 공포
- 소프트웨어 개발과 유통을 촉진함으로서 소프트웨어 산업의 발전과 향후 수출전략산업으로의 육성을 목적으로 함
2) 1988년 10월 20일 [소프트웨어개발촉진법 시행령] 공포
- 소프트웨어개발비 산정의 기준 근거 마련
3) 1989년 4월 과학기술처 고시 제 89-3호에 의거 소프트웨어 개발비 산정기준 고시
4) 1994년 1월 과학기술처 고시 제 94-1호로 1차 개정
- 본수 및 스텝수 방식에 이어 기능점수 산정방식의 개념을 일부 도입
- 소프트웨어 유지보수 대가기준의 신설과 재개발 개념을 도입
- 공정별 생산성 소요공수의 현실화(조정) 및 상세요구분석 공정 소요공수 추가
- 소프트웨어 개발 규모 증감에 따른 사후정산을 제도화
5) 1995년 3월 제2차 개정(정보통신부 고시 제1995-53호)
6) 1995년 12월 법률 제 4997호로 [소프트웨어개발촉진법] 개정
7) 1996년 3월 19일 제 3차 개정(정보통신부 고시 제 1996-21호)
- 소프트웨어 개발에 투입되는 소요인력에 대한 공수 중심의 방식에서 '스텝수'로 표현되는 물량중심의 방식으로 변경
8) 1997년 7월 23일 동법 10조의 규정에 의하여 정보통신부고시 1997-57호로 [소프트웨어 사업대가의 기준]을 제정 고시
- 운용환경구축비, 데이터베이스구축비, 자료입력비, 정보전략계획수립비 산정기준 추가
- 소프트웨어 유지보수대가를 소프트웨어의 활용 특성에 따라 차등지급할 수 있는 근거 마련
9) 2000년 1월 21일 소프트웨어개발촉진법을 소프트웨어산업진흥법[법률 제 6198호]으로 변경 고시
10) 2004년 2월 정보통신부 고시 제 2004-8호로 개정 고시
- 국제 표준의 소프트웨어 규모산정 기준인 기능점수와 소프트웨어 생명주기 중 개발 공정을 도입하여 규모산정 및 적용공정의 정확성 제고
- 보정계수 체계를 현실화하여 정보기술의 발전과 사업환경의 변화에 맞게 조정
- 데이터베이스 구축비 산정 범위 조정
11) 2004년 9월 정보통신부 고시 제 2004-52호로 개정 고시
- 적용 목적을 명확히 정의하여 상위법과의 일관성 확보
- 소프트웨어 개발규모 증감조정 및 개발비 사후정산 관련 조문의 삭제
12) 2005년 5월 정보통신부 고시 제 2005-22호로 개정 고시
- 데이터구축방식에 따른 작업요소 기반의 데이터베이스 구축비 대가기준 개정
13) 2006년 4월 정보통신부 고시 제 2006-18호로 개정 고시
- 소프트웨어 기술자의 등급 및 자격기준 추가
- 정보전략계획수립비, 평균복잡도, 기능점수당 단가, 코드라인당 단가 조정
14) 2007년 6월 정보통신부 고시 제 2007-20호로 개정 고시
- 정보전략계획수립비, 평균복잡도, 기능점수당 단가, 코드라인당 단가 조정
15) 2007년 10월 정보통신부 고시 제 2007-39호로 개정 고시
- 소프트웨어 개발비 산정에 있어 이윤 조정
16) 2009년 5월 지식경제부 고시 제 2009-102호로 개정 고시
- 정보전략계획수립비, 평균복잡도, 기능점수당 단가, 자료입력원 노임단가 조정
- 코드라인 수에 의한 산정방식 폐지
- 투입인력의 수와 기간에 의한 산정방식의 2010년 5월 1일 이후 적용불가
- 소프트웨어 재개발비 산정기준 개정
- 상용 소프트웨어 유지보수 및 소프트웨어 운영 대가기준 추가
17) 2010년 2월 지식경제부 고시 제 2010-52호로 개정 고시
- 대가기준 관리를 위한 전담기관 지정
- 기능점수당 단가 조정
- 2012년 2월 이후 SW사업 대가기준 폐지
□ 기능점수(Function Point)란?
○ 정의
- 사용자 관점에서 측정된 소프트웨어 기능의 규모 즉, 사용자에게 제공된 소프트웨어의 기능적 크기를 측정하는 단위
- 구매, 개발, 유지보수 대상 시스템의 소프트웨어 비용을 관리하기 위한 정량적인 방법
○ LOC(Line of Code)
- 소프트웨어 개발 프로세스 초기에 항상 적용될 수 없음
- 소프트웨어 수명주기에 걸쳐서 항상 동일하게 적용될 수 없음
- 소프트웨어 사용자에게 항상 의미 있는 해석을 줄 수 없음
○ 기능점수는 측정의 초점을 "소프트웨어가 어떻게 구현되었는지"에서 "사용자가 어떠한 기능을 요구했는지"로 이동시킴으로서 이러한 제약사항을 극복할 수 있도록 설계
□ 기능점수 분석의 목적
○ 사용자의 요구에 의해 개발되어 사용자에게 제공되는, 소프트웨어의 기능을 계량
○ 소프트웨어 개발 및 유지보수의 업무량을 구현 기술과는 무관하게 측정
○ 소프트웨어 개발 및 유지보수의 업무량을 전 프로젝트 및 조직에 걸쳐서 일관되게 측정
□ 기능점수의 특성
○ 기능적 사용자 요구사항을 측정
- 어플리케이션이 사용자에게 제공하는 기능
○ 외부 사용자 관점에서 측정
- 어플리케이션 경계 밖의 사용자(사람 또는 타 어플리케이션)의 시각에서 측정 전 수명주기에 걸쳐서 적용
- 개발은 물론 계획, 운영 등 전 단계에서 측정 가능
○ 공수, 적용 방법론, 물리적 또는 기술적 컴포넌트와 무관하게 측정
- 기능규모, 구조적/정보공학적/객체지향, 패키지/COTS 등에 무관하게 측정 가능
□ 기능점수의 유형
○ 데이터 기능
<내부논리파일 (Internal Logical File : ILF)>
- 사용자가 식별할 수 있는 논리적으로 연관된 데이터 그룹 또는 제어정보로 어플리케이션 경계 내부에서 유지
- 주요 의도는 측정 대상 어플리케이션의 하나 또는 그 이상의 단위 프로세스를 통하여 유지되는 데이터를 보관
<외부연계파일 (External Interface File : EIF)>
- 사용자가 식별할 수 있는 논리적으로 연관된 데이터 그룹 또는 제어정보로, 다른 어플리케이션의 경계 내부에서 유지되고 측정 대상 어플리케이션이 참조
- 주요 의도는 측정 대상 어플리케이션의 하나 또는 그 이상의 단위 프로세스를 통하여 유지되는 데이터를 보관
- 특정 어플리케이션에서 외부연계파일(EIF)로 측정된 것은 반드시 다른 어플리케이션의 내부논리파일에 존재해야 함을 의미
○ 트랜잭션 기능
<외부입력 (External Input: EI)>
- 어플리케이션 경계의 밖에서 들어오는 데이터나 제어 정보를 처리하는 단위 프로세스
- 주요 의도는 하나 이상의 ILF를 유지하거나 시스템의 동작을 변경
<외부출력 (External Output: EO)>
- 데이터나 제어 정보를 어플리케이션 경계 밖으로 보내는 단위 프로세스
- 주요 의도는 데이터나 제어 정보의 검색은 물론 처리 로직을 통해 사용자에게 정보를 제공
- 처리 로직은 적어도 하나의 수학 공식, 계산 또는 파생 데이터를 포함하거나, 하나 이상의 ILF를 유지 또는 시스템의 동작도 변경
<외부조회 (External Inquiry: EQ)>
- 데이터나 제어 정보를 어플리케이션 경계 밖으로 보내는 단위 프로세스
- 주요 의도는 ILF나 EIF로부터 데이터나 제어 정보를 검색하여 사용자에게 정보를 제공
- 처리 로직은 수학 공식이나 계산을 포함하지 않으며, 파생 데이터도 생성하지 않고, 처리될 동안 ILF를 유지하지 않으며, 시스템의 동작도 변경하지 않음
□ 기능점수 측정 매뉴얼
CPM은 Counting Practice Manual의 약어로, 기능점수법에 대한 산정절차, 산정기준, 적용사례 등 기능점수 사용자를 위한 실무측정 매뉴얼을 말함
기능점수 실무측정 매뉴얼(CPM)은 한국정보화측정연구원(www.kosma.or.kr)이나 IFPUG (www.ifpug.org)에서 구입할 수 있음
출처 : 정보통신산업진흥원 | 원문자료
출처: https://zzogy.tistory.com/30
기능점수(FP)
I. MM ( Man Month ) 1. S/W 개발비 산정 방법 산정방법 특징 산정 방법 기능점수(FP) 방식 기준 LOC(Line Of Code) 방식 산출물을 대체 소프트웨어 개발 규모와 기능 점수당 단가를 곱하여 소프트웨어 개
zzogy.tistory.com
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) - 블로그
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 유형에 따라 복잡도가 달라 생산성도 달라지는 것을 보정
- 복잡도 증가 = 개발 노력 증가
- 단순 정보처리용 < 통신제어용 < 과학 기술용
- 언어 보정 계수
- 언어에 따라 생산정도 달라지므로 개발 언어에 따른 보정 계수 적용
- 품질/특성 보정 계수
- 보정후 개발 원가 = 보정 전 개발 원가 * (규모보정계수 * 애플리케이션 보정계수 * 언어보정계수 * 품질특성 보정계수)
'프로그램 개발(분석, 설계, 코딩, 배포) > 분석' 카테고리의 다른 글
| 유지관리_SW 유지관리 사업 이해 및 기능점수 (0) | 2022.11.17 |
|---|---|
| 분석_기능점수_기능별 분류 (0) | 2022.11.01 |
| 분석_기능점수_핵심점리 (0) | 2022.11.01 |
| 개발_기능점수_간이법 (0) | 2022.11.01 |
| 기능점수_요약 (0) | 2022.10.31 |
