Function Point(ISO/IEC 14143) 개요
태그 :
- 개념
- 기능점수(Function Point)의 정의 - 소프트웨어의 양과 질을 동시에 고려한 소프트웨어 규모 측정방식 - 정보처리규모와 기능적 복잡도에 의해 소프트웨어 규모를 사용자의 관점에서 측정하는 방식 - 소프트웨어 크기를 결정하는 소프트웨어 기능 유형 별 수량과 성능 및 품질 요인들의 영향도를 고려하여 계산되는 SW 규모 산정방식
- FP의 역사
1975 -IBM의Alan Albrecht에의해Guide/Share 컨퍼런스에서개념소개
1984 –IBM CI/S&A Guideline 313 “AD/M Productivity Measurements & Estimate Validation”.
1986-87 –국제기능점수사용자그룹(IFPUG) 조직. MIT의Chris Kemerer에의해연구가시작
1993 –CFPS(Certification for FP Specialists) 인증시작. QAI/IFPUG 합동연구
1994 –S/W 측정을위한지침인CPM(Counting Practices Manual) 4.0 발표
1995-97 –ISBSG가참여, ISO/IEC JTC1 WG12 Functional Size Measurement에대한연구착수
1998 –ISO/IEC 14143-1 출판2003 –ISO/IEC 14143-1 ~ 5공식적으로표준화됨
2004 –IFPUG CPM 4.2 발표1장-절차와규칙, 2장-측정실무, 3장-예제, 4장-부록및용어
I. FP의 개요
가. 기능점수(Function Point)의 정의
- 소프트웨어의 양과 질을 동시에 고려한 소프트웨어 규모 측정방식
- 정보처리규모와 기능적 복잡도에 의해 소프트웨어 규모를 사용자의 관점에서 측정하는 방식
- 소프트웨어 크기를 결정하는 소프트웨어 기능 유형 별 수량과 성능 및 품질 요인들의 영향도를 고려하여 계산되는 SW 규모 산정방식
나. FP의 특징
- 최종 사용자 입장에서 SW 규모를 측정(개발자 입장에서 SW견적량인 소스코드의 양과 무관)
- 프로젝트 완료 후 생산성 평가를 위해 개발되었으나 사전에 개발소요공수를 예측하는 모델로 사용 가능
- 개발환경과 기술에 무관하게 측정가능하고, 사용자 요구에 따라 시스템 기능 설계 시 개발 중에도 측정 가능함
- 생산성과 품질 등의 척도로도 활용 가능
- FP의 측정을 위해서는 모든 기능과 각 기능별 복잡도가 식별되어야만 함. 제안단계까지는 추정은 가능하나 측정(산정)은 불가능. 따라서 알려지지 않은 기능과 그 기능의 복잡도에 대한 가정 허용
다. FP의 등장 배경
등장 배경 |
내용 |
추정의 어려움 |
SW 개발 초기에 프로그램 LOC 측정 어려움 |
환경의 영향 |
동일한 기능을 하는 SW라도 개발 언어에 따라 SW 라인 수는 크게 다른 문제 발생 |
파라미터의 영향 |
기능은 동일하여도 3단계 CS방식, 1단계 CS방식, 웹 환경 등에 따라 비용 산정의 어려움 |
II. FP의 구성도 및 구성요소
가. 사용자 관점에서 바라본 기능점수의 구성
외부 사용자 관점(측정 대상 어플리케이션 경계 밖의 사용자, 사람 또는 타 어플리케이션)의 시각에서 측정한다.
나. FP의 구성요소
구성요소 |
내용 |
내부논리파일 (ILF) |
측정 범위 내에서 유지되는 논리적 데이터 그룹 또는 제어 정보. 주요 의도는 측정될 어플리케이션의 단위 프로세스를 통해 하나 또는 그 이상의 유지되는 데이터를 보유 |
외부연계파일 (EIF) |
측정 범위 밖의 다른 어플리케이션에서 참조하는 논리적 데이터 그룹 또는 제어 정보. 주요 의도는 어플리케이션의 단위 프로세스에 의해 하나 또는 그 이상의 참조되는 데이터를 보유 |
외부 입력 (EI) |
어플리케이션 외부로부터 데이터 또는 제어 정보를 받아 들여, 내부논리 파일의 유지(추가/수정/삭제등)나 어플리케이션의 상태에 변경을 요구하는 단위 프로세스. 주요 의도는 하나 또는 그 이상의 ILF를 유지하거나 시스템의 상태를 변경 EX) 고객관리 APPLICATION에서 사용자가 자신의 인적사항을 등록하는 기능 (문제에서 입력이 있냐 없냐 파악해야함.) |
외부 출력 (EO) |
어플리케이션 내부에서 데이터 또는 제어 정보를 경계 밖으로 내보낼 것을 요구하는 단위 프로세스. 주요 의도는 처리 로직을 통해 가공된 데이터 또는 제어 정보를 사용자에게 제공해야 한다. 단, 그 처리 로직에는 수학계산, 파생 데이터, ILF유지, 시스템 상태 변경 등 중 하나 포함 EX) 전월 고객전체 과금에서 당월 고객전체 요금과 비교계산해서 현과금의 차이점을 제공하는 보고서(즉 계수화가 되면 외부출력으로 봐야함) |
외부 조회 (EQ) |
어플리케이션 내부에서 데이터 또는 제어 정보를 경계 밖으로 내보낼 것을 요구하는 단위 프로세스. 주요 의도는 ILF 또는 EIF로부터 데이터 또는 제어 정보를 조회하여 사용자에게 제공해야 한다. 단, 처리 로직에는 수학계산, 파생 데이터, ILF유지, 시스템 상태 변경 등이 없어야 한다. EX) 고객의 회원정보를 리스트를 조회하여 고객에게 제공하는 기능 (만약 여기서 정보를 계산(계수화)하면 외부출력으로 봐야함) |
III. FP 프로세스 및 프로세스 상세 설명
가. FP 프로세스(IFPUG)
나. FP 측정절차의 구성요소
1. 측정 유형 결정
종류 |
내용 |
개발프로젝트 |
SI 프로젝트가 종료된 후, 사용자에게 인도되는 SW |
개선프로젝트 |
SW 추가, 수정, 삭제 부분에 대한 SW 비용 산정 |
어플리케이션 |
사용자가 사용하고 있는 SW의 현재 기능 측정 |
2. 측정 범위와 어플리케이션 경계 식별
구분 |
종류 |
내용 |
측정범위와 어플리케이션 경계식별 |
범위 결정 |
개별 변경할 SW에 대한 전체 범위 결정 |
경계 분류 |
각 어플리케이션간의 경계를 분류하는 과정(ILF와 ELF를 구분하기 위함) |
- 사용자와 어플리케이션 경계 식별 구성도
3. 데이터 기능 측정
DET = (부서번호, 부서명, 사원번호, 사원이름, 주소) RET = (부서, 사원) |
- 데이터 기능점수 산정은 ILF와 EIF를 식별하는 것이며 그 후 각각 복잡도와 기여도를 결정하여 데이터 기능점수를 도출
구분 |
유형 |
설명 |
데이터 기능 유형 식별 |
내부논리파일(ILF) |
사용자가 식별할 수 있는 논리적으로 연관된 데이터 그룹 또는 제어 정보 어플리케이션 경계 내부에서 유지 |
외부연계파일(EIF) |
데이터 그룹은 측정되는 어플리케이션 외부에서 참조 다른 어플리케이션의 ILF로 유지 |
구분 |
유형 |
설명 |
복잡도 및 기여도 결정 |
데이터요소유형 (DET) |
사용자가 식별 가능하고 반복되지 않는 유일한 필드 단위 프로세스의 실행을 통하여 ILF 또는 EIF에서 유지 또는 검색되고 사용자가 식별 가능하며 반복되지 않는 유일한 필드를 하나의 DET로 측정 |
레코드요소유형 (RET) |
사용자가 식별 가능한 데이터 요소의 서브 그룹 ILF나 EIF의 서브그룹 각각의 하나를 RET로 측정 서브그룹이 없다면 ILF나 EIF를 하나의 RET로 측정 |
4. 트랜잭션 기능 측정
구분 |
유형 |
설명 |
트랜잭션 기능 유형식별 |
외부입력(EI) |
데이터 또는 제어정보를 어플리케이션 경계 밖에서 받아들임 어플리케이션 경계를 통해 들어 온 데이터가 시스템의 동작을 바꾸는 제어정보가 아니라면 적어도 하나의 ILF유지 |
외부출력(EO) |
데이터 또는 제어정보를 어플리케이션 경계 밖으로 보냄 처리 로직이 어플리케이션 내 다른 외부 출력의 처리 로직과 구분 하나의 수학공식이나 측정 포함, 계산 데이터 생성, 시스템 동작 변경 |
|
외부조회(EQ) |
데이터 또는 제어정보를 어플리케이션 경계 밖으로 보냄, 있는그대로 처리 로직이 어플리케이션 내 다른 외부 출력의 처리 로직과 구분 ILF나 EIF로부터 데이터나 제어 정보를 검색, 수학공식이나 측정 불포함, 계산 데이터 생성하지 않음 |
|
복잡도 및 기여도 결정 |
데이터요소유형(DET) |
사용자가 식별 가능하고 반복되지 않는 유일한 필드 단위 프로세스 수행 중 시스템에 의해 검색되거나 파생되어 ILF에 저장되는 필드 |
참조파일유형(FTR) |
트랜잭션 기능에 의해 읽히거나 유지되는 내부논리 파일 트랜잭션 기능에 의해 읽히는 외부 참조 파일 |
5. 미조정 기능점수(UFP, Unadjusted Function Points) 결정
- 데이터 기능 점수와 트랜잭션 기능 점수의 합
6. 조정인자(VAF, Value Adjustment Factor) 결정
단계 |
활동 |
|
1 |
14개의 일반 시스템 특성 각각에 대해 영향도 결정(0~5점) |
|
2 |
각각의 영향도를 합하여 총 영향도 산출(0~70점) |
|
3 |
총 영향도를 다음의 방정식에 대입하여 조정인자를 산출 조정인자(VAF) = (총 영향도 * 0.01) + 0.65 |
|
14개 일반 시스템 특성(GSC) 데이터 통신(Data Communications) 분산 데이터 처리(Distributed Data or Processing) 성능(Performance) 사용환경(Heavily Used Configuration) 처리율(Transaction Rate) 온라인 데이터 입력(OnLine Data Entry) 최종 사용자 효율성(End-user Efficiency) 온라인 갱신(Online update) 처리 복잡도(Complex Processing) 재사용성(Reusability) 설치 용이성(Installation Ease) 운영 용이성(Operation Ease) 복수 사이트(Multiple site) 변경 용이성(Facilitate Change) |
||
Data communications (데이터 통신) |
어플리케이션이 프로세서와 직접적으로 통신하는 정도를 나타내는 특성 |
|
Distributed Data Processing (분산 데이터 처리) |
애플리케이션의 컴포넌트 사이에 데이터 전송하는 정도를 나타내는 특성 |
|
Performance (성능) |
애플리케이션 개발에 영향을 주는 응답 시간(response time)과 처리율(throughput)의 performance를 고려하는 정도를 나타내는 특성 |
|
Heavily used Configuration (사용환경) |
애플리케이션 개발에 영향을 주는 컴퓨터 자원의 정도를 나타내는 특성 |
|
Transaction rate (처리율) |
애플리케이션 개발에 영향을 주는 비즈니스 트랜잭션의 비율을 나타내는 특성 이 특성이 높을 시 애플리케이션의 설계,개발,설치,지원에 영향을 미침 |
|
Online data entry (온라인 데이터 입력) |
데이터가 대화식(interactive) 트랜잭션을 통해 입력되는 정도를 나타내는 특성 |
|
End user efficiency (최종 사용자 효율성) |
Human factors와 사용의 용이성을 나타내는 특성 Human Factors : 인간의 여러 특성, 예컨대 지각, 주의, 기억, 학습, 스트레스, 생리, 신체 등이 산업 장면에 어떻게 관련되는지에 대한 연구분야 |
|
Online update (온라인 갱신) |
내부 논리 파일이 온라인으로 갱신되는 정도를 나타내는 특성 |
|
Complex processing (처리 복잡도) |
프로세싱 논리가 애플리케이션의 개발에 영향을 미치는 정도를 나타내는 특성 |
|
Reusability (재사용성) |
다른 애플리케이션에서 이용 가능하도록 애플리케이션과 애플리케이션 내의 코드가 특별하게 설계, 개발, 지원되는 정도를 나타내는 특성 |
|
Installation ease (설치 용이성) |
애플리케이션개발에 이전 환경의 컨버전이 영향을 주는 정도를 나타내는 특성 |
|
Operational ease (운영 용이성) |
시동, 백업, 복구 절차와 같은 운영 측면에 주의하는 정도를 나타내는 특성 |
|
Multiple sites (복수 사이트) |
여러 장소의 사용자 조직을 위해 개발되는 정도를 나타내는 특성 |
|
Facilitate change (변경 용이성) |
변경을 쉽도록 하기 위해 애플리케이션이 특별하게 설계, 개발, 지원되는 정도를 나타내는 특성 |
국내-SW대가산정법 조정인자 (4가지)
1. 규모 보정 계수 - FP가 300미만이면 0.65 - FP가 300이상이면 (0.108*Log e(FP값)+0.229) 2. 어플리케이션 유형 보정 계수
3. 언어 보정 계수
4. 품질 및 특성 보정계수 = 0.025 * 총 영향도 + 1 - 총 영향도 = 분산처리 + 성능 + 신뢰성 + 다중사이트 영향도
|
7. 조정 기능점수(AFP, Adjust Function Point) 결정
- 개발 프로젝트 기능 점수 계산 공식
DFP = (UFP + CFP) * VAF
구분 |
설명 |
DFP |
개발 프로젝트 기능 점수 |
UFP |
미조정된 기능 점수 |
CFP |
데이터의 컨버전에 의해 포함되는 기능 점수 |
VAF |
값 조정 인자 |
- 개선 프로젝트 기능 점수 계산 공식
EFP = [ ( ADD + CHGA + CFP ) * VAFA ] + ( DEL * VAFB )
구분 |
설명 |
EFP |
개선 프로젝트 기능 점수 |
ADD |
개선 프로젝트에 의해 추가된 기능들의 미조정된 기능 점수 |
CHGA |
개선 프로젝트에 의해 수정된 기능들의 미조정된 기능 점수 |
CFP |
데이터의 컨버전에 의해 포함된 기능 점수 |
VAFA |
개선 프로젝트 이후의 애플리케이션의 값 조정 인자 |
DEL |
개선 프로젝트에 의해 삭제된 기능의 미조정된 기능 점수 |
VAFB |
개선 프로젝트 이전의 애플리케이션의 값 조정 인자 |
- 애플리케이션 기능 점수 계산
초기의 애플리케이션 기능 점수 계산 공식
AFP = ADD * VAF
구분 |
설명 |
---|---|
AFP |
초기의 기능 점수 |
ADD |
개발 프로젝트에 의해 설치된 기능의 미조정된 기능 점수 |
VAF |
값 조정 인자 |
확장 후의 애플리케이션 기능 점수 계산 공식
AFP = [ ( UFPB + ADD + CHGA ) – ( CHGB + DEL ) ] * VAFA
구분 |
설명 |
---|---|
AFP |
애플리케이션의 조정된 기능 점수 |
UFPB |
확장 프로젝트에 의해 추가된 기능의 미조정된 기능 점수 |
ADD |
확장 프로젝트에 의해 추가된 기능의 미조정된 기능 점수 |
CHGA |
확장 프로젝트에 의해 변경된 기능의 미조정된 기능 점수 (변경 후의 기능 점수 값을 반영) |
CHGB |
변경 이전에 확장에 의해 변경된 기능의 미조정된 기능 점수 (확장 프로젝트 이전의 기능 점수 값을 반영) |
DEL |
확장 프로젝트에 의해 삭제된 기능의 미조정된 기능 점수 |
VAFA |
확장 프로젝트 이후 애플리케이션의 값 조정 인자 |
IV. FP 국내 동향, 효과, 문제점 및 개선방향
가. 국내 동향
- 2004년 2월 정통부에 의해 국제표준의 FP모델에 의한 규모산정방식 도입, 기업회계 기준에 의한 통합단가체계 도입, 최신의 정보기술 동향을 감안한 새로운 보정체계를 도입한 개정 사업대가 기준 발표
- 2002년 한국정보기술원가표준원(KFPUG)발족하고 2004년 CFPS자격시험 시행
- 우리나라는 전세계에서 FP를 가장 활발하게 활용하는 나라로 국제무대에 알려짐
나. 효과
- 벤치마킹 조사, 개발 비용산정, 프로세스 개선 분석
- 유지보수 비용 산정,아웃소싱 계약, 품질비용 산정
- 패키지를 포함한 모든 기능을 측정하여 응용패키지의 규모 산정
- 소프트웨어 제품별 품질과 생산성 분석을 위한 측정도구로 활용
- 소프트웨어 개발,유지보수에 요구되는 비용,자원 산정
다. 문제점
- Data Function : 사용자 관점에서 측정되기 때문에 감추어진 EI, EO, EQ를 찾기가 어려움
- Transaction Function : 사용자 관점에서 사용되는 파일 수를 정확히 찾기 어려움
- 기술 복잡도 측면 : 14개 항목에 대한 측정자의 주관적 의지 반영
라. 개선방향
- 감추어진 기능이나 복잡도 산정에 대해 지속적인 연구가 필요
- Feature Point, COCOMO2등에서 복잡하거나 Embedded시스템에 대한 규모산정을 더욱 과학적으로 보완
- 과거 독자모델 추구시대에서 국제표준 채택으로 변화
- FP가 S/W규모 측정기준에서 생산성, 품질, 원가, 일정, 요원, 요구변경, 아웃소싱 계약에 표준 또는 핵심요소로 활용
- FP 복잡도를 낮추고 가치 점수 모형의 변화 등의 도입
- 소프트웨어 유지보수,시스템 운영 등을 반영하는 비용을 산출해야 함
- 소프트웨어 개발 공수 현실화 필요
V. 비용 산정 방식 비교
가. FP 정규법과 간이법 비교
구분 |
정규법 |
간이법 |
---|---|---|
개념 |
논리적인 설계를 바탕으로 한, 각 기능의 속성을 정의하여 기능별 복잡도 매트릭에 의한 기능점수 산정 방식 |
개략적인 사용자 요구사항을 바탕으로 기능점수를 도출하여 평균복잡도에 의한 기능 점수 산정 방식 |
사용시기 |
상세한 기능점수 측정 |
프로젝트 초기에 측정 |
사용목적 |
SW 분석/설계, 개발, 유지보수의 개발범위, 일정 및 원가 산정 |
예산 수립, 제안서 견적 산정, 계약의 SW 사업대가 산정 |
측정항목 |
데이터 기능 및 DET, RET 수 도출 DET : Data Element Type RET : Record Element Type
트랜잭션 기능 및 DET, FTR 식별 DET : 데이터 항목 수(ILF에 저장되는 수) FTR : File Type Reference (참조파일 수) ILF, EIF를 지칭함 |
데이터 기능, 트랜잭션 기능 |
복잡도 |
기능별 복잡도 매트릭(Low, Avg, High) |
평균 복잡도 |
다. FP와 COCOMO(Constructive Cost Model) 비교
구분 |
Function Point |
COCOMO |
정의 |
어플리케이션이 제공하는 기능의 크기를 나타내는 수치 개발하려는 SW 기능의 총 규모(SIZE) X 단위규모당 단가 X 보정요소 |
Barry Boehm이 제창한 소프트웨어 견적 모델로서 프로그램 Line 수를 이용하는 가장 대표적인 모형 모형은 Boehm이 63개의 프로젝트 데이터를 3가지 유형으로 분류, 소요공수 모델을 도출 |
특징 |
사용자 관점에서 기능을 측정 “How”가 아닌 “What”의 문제 : 기술과는 무관하게 측정 논리설계에 기초 : 요구사항에 일치하는 어플리케이션 기능을 측정 모호성을 줄이기 위해 측정 단위를 아주 상세화 프로젝트 및 조직에 무관한 일관된 기준 |
구조적 코스트 모델이라는 의미를 갖고 있으며, 코스트 견적과 평가를 위한 모델 개발규모를 알고 있는 경우에, 작업량이나 공기를 견적하는데 유효한 방법 계산된 기본 소요공수를 프로젝트의 특성 요소를 반영하여 보정 |
장점 |
SW개발규모의 정량화 가능 국제표준의 채택으로 해외시장 진출 발판 마련 발주자와의 가격, 납기 교섭의 기초 값으로 활용 가능 개발비, 개발기간, 소요공수, 견적/진척 관리의 Parameter 로의 사용으로 시험밀도, 벅(Bug)밀도의 분포 등을 분석 자산관리(포트폴리오분석)에의 사용 |
소프트웨어의 생산성 평가를 지향하고 있는 모델로서, 코스트 절감을 위한 평가를 다음 견적에 활용 개발규모를 알고 있는 경우의 견적 방법이기 때문에, 개략견적 시 보다 상세 견적 시에 더욱 유효. |
라. FP와 LOC 비교
- LOC란 소프트웨어 각 기능의 LOC(원시 코드 라인 수)의 낙관치, 기대치, 비관치를 측정하여 예측치를 구하고 이것으로 비용을 산정하는 기법
- 예측치 = (낙관치 + 4 * 기대치 + 비관치) / 6
구분 |
FP |
LOC |
특징 |
기능 중심의 산정 |
크기 중심의 산정 |
장점 |
기능 고려, LOC 단점 보완 |
사용이 쉬움 |
단점 |
복잡도 산정 è 주관 개입 |
단순, 코드 재사용 무시 등 |
<참고자료>
- SW 개발비용 산정 방식
구분 |
설명 |
주요기법 |
하향식 산정방법 |
경험자의 경험과 전문지식, 합의로 산정 |
|
상향식 산정방법 |
각 업무분류 별로 산정, 분류 별 산정내용을 집계 |
|
수학적 산정방법 |
수학적 방법 적용, 개발비 산정 자동화 |
|
- SW 개발비 산정
개발비 + 직접경비 + 이윤(개발비의 25% 이내)
- IFPUG, 지식경제부의 FP방식의 SW개발비 산정방식 비교
구분 |
IFPUG 방식 |
지식경제부 방식 |
특징 |
보정절차가 완료된 ‘조정 기능점수(AFP)’에 FP당 단가를 대입하여 개발원가 산출 |
‘ 미조정 기능점수(UFP)’에 FP당 단가를 대입하여 ‘보정 전 개발원가’를 산정하고 보정계수를 대입하여 개발원가 산출 |
산정 절차 |
|
|
보정 계수 |
|
|
- 지식경제부 FP방식의 개발원가 산출기준
- 보정전 개발원가 = 기능점수(UFP) X 기능점수당 단가
단계 |
분석 |
설계 |
구현 |
시험 |
합계 |
단가 (단위:원) |
94,511 |
119,382 |
159,177 |
124,357 |
497,427 |
- 개발원가 = 보정전 개발원가 X (규모 보정계수 X 어플리케이션유형 보정계수 X 개발언어 보정계수 X 품질 및 특성 보정계수)