기능 점수 분석
(Function Point Analysis)
기능 점수 분석 (Function Point Analysis)
1
차 례
1. 기능 점수 분석 개요
2. 데이터 기능의 크기 측정
3. 트랜잭션 기능의 크기 측정
4. 일반 시스템 특성
5. 기능 점수의 계산과 응용
6. 사례 연구
기능 점수 분석 (Function Point Analysis)
2
1
기능 점수 분석 개요




배경
기능 점수 계산 과정
기능 점수의 유형
계산 범위와 어플리케이션의 경계
기능 점수 분석 (Function Point Analysis)
3
배경



기능 점수 분석(Function Point Analysis: FPA)은 소프트웨어
개발 프로젝트 혹은 설치된 소프트웨어 어플리케이션의 크기를
측정하는 방법론
FPA는 이미 검증되었고, 미국, 영국, 호주, 오스트리아, 브라질,
덴마크, 독일, 이탈리아, 일본, 네덜란드, 남아프리카 공화국 등을
비롯한 세계 각국에서 일반적으로 널리 받아들여진 방법론
FPA는 새로운 기술들의 발전과 동시에 재검토되고,
분명해졌으며, 갱신되고 있음
» 일관성 향상되고 어플리케이션의 크기와 노력간의 관련성이 개선

최근의 기준은 IFPUG 계산 실무 위원회에서 발표한
지침서(Counting Practices Manual) 버전 4.1
기능 점수 분석 (Function Point Analysis)
4
배경 (계속)



FPA는 소프트웨어 크기를 측정하기 위해 일반적으로 인정된
표준
FPA는 비용 산정 과정 초기에 도입될 수 있음
기능 점수로 측정한 크기는 어플리케이션 속성(성능, 보안성
등)과 프로젝트 속성(기술 수준, 언어, 방법론 등)과 함께 사용
» 기능 점수는 영역이 변경되거나 개발 과정의 새로운 단계가 시작될
때마다 다시 계산되어야 함

기능 점수는 사용자가 요구하는 기능을 표현해야 하므로 초기에
기능 분석이 가능하고 의미가 있음
» 프로젝트 제안 단계 초기에 이해당사자가 함께 모이는 것이 개발
작업을 쉽게 하고 사용자가 실제 원하는 것을 분명하게 할 수 있음

소프트웨어 기능의 계량화를 위해 개발 단계와 유지 보수
단계에서 적용
기능 점수 분석 (Function Point Analysis)
5
기능 점수 계산 과정
1. 기능 점수의 유형 결정
2. 기능 점수 계산 범위와 어플리케이션 경계를 식별
3. 데이터 기능(내부 논리 파일, 외부 인터페이스 파일)과
복잡도 계산
4. 트랜잭션 기능(외부 입력, 외부 출력, 외부 조회)과
복잡도 계산
5. 미조정된 기능 점수(unadjusted function point) 계산
6. 일반 시스템 특성에 근거한 값 조정 인자 계산
7. 조정된 기능 점수(adjusted function point) 계산
기능 점수 분석 (Function Point Analysis)
6
기능 점수 계산 과정 (계속)

기능 점수의 유형
» 개발 프로젝트 기능 점수
» 확장 프로젝트 기능 점수
» 어플리케이션 기능 점수

기능 점수 계산 범위와 어플리케이션 경계를 식별
» 계산 범위는 크기를 측정하기 원하는 범위
» 어플리케이션의 경계는 측정되는 어플리케이션과 다른 독립적인
어플리케이션을 구분

데이터 기능(내부 논리 파일, 외부 인터페이스 파일)과 복잡도
계산
» 데이터 기능은 갱신과 검색을 위해 저장되어 활용 가능한 논리
데이터와 파일

트랜잭션 기능(외부 입력, 외부 출력, 외부 조회)과 복잡도 계산
» 트랜잭션 기능은 데이터의 유지보수, 검색, 출력 등을 수행
기능 점수 분석 (Function Point Analysis)
7
기능 점수 계산 과정의 예
예: 각 직원의 근무 위치 정보를 유지하고 디스플레이하는 Location
어플리케이션
Building
request, retrieve, display
Security
information from Location
and Personnel
Location
Location Directory Data
Clerk
print monthly
listing
update
directory
Location
Listing
Personnel
Employee Data
determine
if employee
기능 점수 분석 (Function Point Analysis)
8
기능 점수 계산 준비
예: 각 직원의 근무 위치 정보를 유지하고 디스플레이하는
Location 어플리케이션
단계 1. 기능 점수 유형
개발 이력에 상관 없이 현재의 어플리케이션을 계산하므로 기능
점수의 유형은 어플리케이션 기능 점수
단계 2. 계산 범위와 어플리케이션 경계
범위: 어플리케이션에 존재하는 모든 기능
경계: Location, Location Listing, Clerk, Building Security, Personnel
기능 점수 분석 (Function Point Analysis)
9
기능 점수 계산 준비
단계 3. 데이터 기능 (ILF, EIF)
내부 논리 파일(ILF) - Location Directory Data : Location
어플리케이션의 경계 안에서 유지
외부 인터페이스 파일(EIF) - Employee Data : Location
어플리케이션이 데이터검색을 위해 이용하지만 Personnel
어플리케이션 경계 내에서 유지
단계 4. 트랜잭션 기능 (EI, EO, EQ)
외부 입력(EI) - Clerk : Location Directory Data를 갱신
외부 출력(EO) - Location Listing : 총 직원에 대한 자료 생성
외부 조회(EQ) – Building Security : Location Directory Data ILF와
Employee Data EIF 내에 유지되는 정보의 검색과 디스플레이
기능 점수 분석 (Function Point Analysis)
10
기능 점수 계산에 유용한 정보


개발의 초기 단계에서 활용할 수 있는 정보의 양은 적지만,
개발이 진행됨에 따라 활용할 수 있는 정보의 양이 많아짐
유용한 정보를 얻을 수 있는 문서의 종류
»
»
»
»
»
»
»
»
»
»
»
프로젝트 제안서
고수준의 시스템 다이어그램
ER 다이어그램
논리 데이터 모델
데이터 흐름도
객체 모델
프로세스 모델
요구 문서
프로토타입
기능 명세서
유스 케이스
기능 점수 분석 (Function Point Analysis)
11
기능 점수 계산에 유용한 정보 (계속)

유용한 정보를 얻을 수 있는 문서의 종류 (계속)
»
»
»
»
»
»
»
»
»
»
»
»
시스템 명세서
상세 설계 명세서
물리 설계 모델
운영 모델
프로그램과 모듈 명세서
파일 배치도
데이터베이스 배치도
스크린 출력
리포트 배치도
테스트 케이스
사용자 매뉴얼과 기술 문서
시스템 도움말(help)
기능 점수 분석 (Function Point Analysis)
12
기능 점수의 유형

개발 프로젝트 기능 점수
» 처음 설치된 어플리케이션을 통해 사용자에게 제공되는 기능을 측정
» 초기의 어플리케이션 기능 점수로 계산되는 기능과 데이터 컨버전을 위해
필요한 기능 포함
– Location 어플리케이션을 새로 개발되는 어플리케이션으로 대치하면, 새로운
어플리케이션이 제공하는 기능 뿐만 아니라 예전 데이터 파일의 데이터를 새로운
데이터 파일로 변환하는 컨버전 기능을 함께 계산
» 원점에서 시작하는 계산이 아니라 이전에 인식된 기능을 검증하여 기능을
추가하는 연속적인 기능 점수 계산
» 프로젝트 개발 동안의 계산
Requirements
Function
Point
Count
Initial
Design
Detailed
Design
Function
Point
Count
Coding
Testing
Implementation
Maintenance
Function
Point
Count
Function
Point
Count
Function
Point
Count
기능 점수 분석 (Function Point Analysis)
13
기능 점수의 유형 (계속)

확장 프로젝트 기능 점수
» 새로운 기능의 추가, 예전 기능의 제거, 기존 기능의 변경을
포함하여 기존 어플리케이션을 수정하여 사용자에게 제공되는 기능

어플리케이션 기능 점수
» 설치된 어플리케이션이 최종사용자에게 제공하는 현재의 기능
» 현재 활용되고 유지되는 어플리케이션의 기능 점수
» 기준선(baseline)에 해당
기능 점수 분석 (Function Point Analysis)
14
계산 범위와 어플리케이션의 경계

기능 점수의 계산 범위는 목적에 의해 결정
» 크기를 측정하기 원하는 범위
» 크기를 측정할 시스템, 어플리케이션, 어플리케이션의 부분
집합
» 상용 패키지의 구입, 아웃소싱 어플리케이션, 특정 목적의
어플리케이션의 기능 포함

어플리케이션의 경계는 측정되는 어플리케이션과
외부 어플리케이션 혹은 사용자 영역 사이의 경계
» 측정되는 어플리케이션과 다른 독립적인 어플리케이션 혹은
사용자 영역을 구분
기능 점수 분석 (Function Point Analysis)
15
기능 점수 계산을 위한 구성 요소
External User
External External External
Input
Output
Inquiry
Internal
Logical File
External
Interface File
External Input
External Output
Application Boundary
Other Applications
기능 점수 분석 (Function Point Analysis)
16
어플리케이션 경계를 식별하는 규칙

어플리케이션 경계는 사용자 뷰(user’s view)에 기반을 둠
» 사용자의 언어로 어플리케이션의 범위와 비즈니스 기능을 정의

관련된 어플리케이션 사이의 경계는 기술적 요소보다는
비즈니스 측면의 기능에 기초함
» MS Office는 Word, Excel, PowerPoint, Access로 구성되고, 각각은
별도의 MS Office 내의 어플리케이션

확장 중인 어플리케이션에 대한 초기의 어플리케이션 경계는
확장과 함께 변경됨
» 추가된 기능은 경계를 확장시키고 삭제된 기능은 경계를 축소시킴
» 변경된 기능은 어플리케이션의 기능 점수의 크기를 변경시킬 수
있음
» 개발 프로젝트와 확장 프로젝트는 단일 어플리케이션 이상을
포함하고, 다중 어플리케이션의 경계는 계산 범위 내에 포함되지만
별도로 계산
기능 점수 분석 (Function Point Analysis)
17
Accounting System의 어플리케이션 경계
Accounting
System
Accounts
Receivable
General
Ledger
기능 점수 분석 (Function Point Analysis)
Accounts
Payable
18
Production System의 어플리케이션 경계
Production
System
Shop
Planner
Material
Inventory
기능 점수 분석 (Function Point Analysis)
Work
Schedule
19
2
데이터 기능의 크기 측정




개요
데이터 기능의 유형
ILF와 EIF의 복잡도
ILF와 EIF의 계산 예
기능 점수 분석 (Function Point Analysis)
20
개요



데이터 기능은 저장된 논리 데이터와 관련이 있으며 갱신, 참조,
검색을 위해 활용될 수 있음
데이터 기능은 내부 논리 파일(ILF)이나 외부 인터페이스
파일(EIF)로 식별되는데, 이들은 모두 논리적으로 관련된
데이터나 제어 정보의 그룹으로 사용자가 식별 가능해야 함
어플리케이션의 물리적 파일 구조의 구현에 관련 없이 ILF와
EIF의 수가 동일하게 식별되어야 함
» Flat file, IDMS 데이터베이스, IMS 데이터베이스, 관계형
데이터베이스, DB2 테이블, 객체


ILF는 기능 점수를 측정하려고 하는 어플리케이션의 경계 내에서
유지됨
EIF는 기능 점수를 측정하려고 하는 어플리케이션의 경계 내에서
판독, 참조되지만 상이한 어플리케이션 경계 내에서 유지됨
기능 점수 분석 (Function Point Analysis)
21
기능 점수 계산 과정
1. 기능 점수의 유형 결정
2. 기능 점수 계산 범위와 어플리케이션 경계를 식별
3. 데이터 기능(내부 논리 파일, 외부 인터페이스 파일)과
복잡도 계산
4. 트랜잭션 기능(외부 입력, 외부 출력, 외부 조회)과
복잡도 계산
5. 미조정된 기능 점수(unadjusted function point) 계산
6. 일반 시스템 특성에 근거한 값 조정 인자 계산
7. 조정된 기능 점수(adjusted function point) 계산
기능 점수 분석 (Function Point Analysis)
22
데이터 기능을 먼저 계산하는 이유
1. 트랜잭션 기능의 복잡도를 계산하기 위해서는 어느 ILF와 EIF가
각 트랜잭션 기능에 의해 유지, 참조되는지 알아야 함.
» 각 데이터 기능과 트랜잭션 기능은 표준 행렬을 기초로 low,
average, high 중의 하나로 가중치가 할당됨
2. 데이터베이스 파일을 먼저 식별하고, 다음에 트랜잭션 기능을
식별함에 따라 이전에 ILF와 EIF로 지정한 것이 타당하지 검증할
수 있음
» Location 어플리케이션(예)에서 ILF인 Location Directory Data는
어플리케이션의 경계 내에서 유지됨
» EIF인 Employee Data는 Personnel 어플리케이션의 경계 내에서
유지되고 데이터의 참조를 위해 Location 어플리케이션에서 이용됨
» 그 결과로 ILF로 계산되는 데이터의 논리적 그룹은 Location
어플리케이션 내에서 최소한 하나의 외부 입력(EI)에 의해
갱신되거나 유지되어야 함
기능 점수 분석 (Function Point Analysis)
23
데이터 기능의 유형
ILF와 EIF 개요
1. 내부 논리 파일(ILF)
» ILF는 EI, EO, EQ에 의해 읽히거나 참조되어야 함
» ILF는 대개 기능 점수를 계산 중인 어플리케이션에서 항상 읽히거나
참조되지만, 다른 어플리케이션 내에서 읽히거나 참조될 수 있음
2. 외부 인터페이스 파일(EIF)
» EIF가 다른 어플리케이션에서 유지된다고 하더라도 논리적인
그룹의 일부 데이터는 기능 점수를 계산 중인 어플리케이션 내에서
최소한 하나의 EI, EO, EQ에 의해 읽히거나 참조되어야 함
» 데이터는 편집, 디스플레이, 계산, 비교를 위한 검색시 읽히거나
참조됨
기능 점수 분석 (Function Point Analysis)
24
데이터 기능의 유형: ILF

정의: ILF는 어플리케이션의 경계 내에서 유지되는
논리적으로 관련된 데이터나 제어 정보로 사용자가
식별 가능한 그룹
» 의미: 기능 점수를 계산 중인 어플리케이션의 하나 이상의
기본적인 프로세스를 통해 유지되는 데이터
» 사용자가 식별 가능하다는 것은 사용자와 소프트웨어 개발자
모두가 이해하고 동의한 요구사항, 데이터 그룹
– 예: financial application의 checking account record
기능 점수 분석 (Function Point Analysis)
25
데이터 기능의 유형: ILF (계속)

정의
» 논리적으로 관련된다는 것은 각 그룹이 논리적으로 적합해야
한다는 요구조건
–
–
–
–
ILF는 다른 ILF에 종속되거나 한정되지 않아야 함
성능이나 구현 상의 이유로 생성된 그룹들은 합병되어야 함
제2정규형이나 제3정규형의 엔터티 타입
데이터 흐름도(Data Flow Diagram)의 데이터 저장소(Data
Store)에 해당
– 예: 주소 테이블은 고객 파일, 거래 파일, 재고품 위치 파일, 직원
파일과 같은 논리적 그룹에 해당
기능 점수 분석 (Function Point Analysis)
26
데이터 기능의 유형: ILF (계속)

정의
» 데이터는 어플리케이션 내에서 유지되는 사실(facts),
수(figures) 등의 모임
– check number, amount, date, payee, memo entry, account
number는 checking account record 내에 유지됨
» 제어 정보는 어플리케이션의 기본 프로세스에 영향을 주기
위해 어플리케이션에 의해 이용되는 데이터
– 어떤 데이터가 언제 어떻게 처리되는지를 규정
– 예: Printer Manager 내에 유지되는 제어 데이터, 부정확하거나
부적절한 데이터를 거부하기 위한 편집 데이터, 이벤트의
순서와 타이밍을 설정하는 날짜와 시간, 이벤트를 제어하기
위한 threshold
기능 점수 분석 (Function Point Analysis)
27
데이터 기능의 유형: ILF (계속)

정의
» 유지(maintain)된다는 것은 어플리케이션의 기본 프로세스
동안 데이터가 수정된다는 사실을 의미
– 데이터와 제어 정보를 유지하는 트랜잭션의 예: add, bill,
change, delete, evaluate, fail, grant, hold, populate, revise,
update
– ILF는 여러 어플리케이션에 의해 유지되거나 ILF로서 계산될 수
있지만, 어플리케이션 당 하나로 계산됨
» 기본 프로세스는 사용자에게 의미 있는 가장 작은 작업 단위
– 창고에서 물건을 출하(issue)하는 것은 CRUD 서브 프로세스로
분할될 수 있으나, 출하가 기본 프로세스
– 동일 트랜잭션으로 여러 ILF 갱신 가능
기능 점수 분석 (Function Point Analysis)
28
IFPUG의 ILF 계산 규칙

데이터나 제어 정보의 그룹은 논리적이고 사용자가 식별
가능하다.

데이터 그룹은 기능 점수가 계산되는 어플리케이션의 경계
내에서 기본 프로세스를 통해 유지된다.
» 데이터 그룹은 어플리케이션 내에서 일단 ILF로 식별되고 나면, 비록
다른 트랜잭션에 의해 참조 목적으로 이용된다고 해도 동일한
어플리케이션 내에서 또 다시 EIF로 계산될 수 없고, 그
어플리케이션의 확장 프로젝트에서도 EIF로 계산될 수 없음
기능 점수 분석 (Function Point Analysis)
29
ILF의 공통적인 예

어플리케이션 트랜잭션 데이터
» transaction issue record, employee training record, payroll record,
credit card transaction, product sales, customer call, accounts
payable





어플리케이션 내에서 유지되는 보안(security) 데이터 혹은
패스워드 데이터
어플리케이션 내에서 유지되는 HELP 데이터
어플리케이션 내에서 유지되는 Edit 데이터
어플리케이션 내에서 유지되는 Parameter 데이터
어플리케이션 내에서 유지되는 에러 파일과 에러
기술(description)
기능 점수 분석 (Function Point Analysis)
30
ILF로 잘못 식별되는 예




임시 파일이나 다양하게 반복되는 동일한 파일
작업 파일
정렬 파일
디스플레이나 프린트에 앞서서 다른 ILF나 EIF에서 추출된
데이터를 포함하는 extract file 혹은 view file
» EO나 EQ를 생성하는데 필요한 파일의 일부




기술적인 이유로 도입된 파일
동일한 파일의 사본
별도로 유지되는 대치 색인(alternative index), 조인(join),
관계(relationship)
감사(audit) 데이터나 이력 데이터
» 어플리케이션 트랜잭션 데이터에서 함께 계산되어야 함
기능 점수 분석 (Function Point Analysis)
31
ILF로 잘못 식별되는 예 (계속)

다른 어플리케이션 내에서 유지되거나 단지 읽히거나
참조되기만 하는 파일
» EIF로 계산되어야 함

공동의 백업과 복구를 위해 이용되는 백업 데이터
» 일반 시스템 특성(GSC)에서 인식됨

별도로 유지되지 않는, 불완전한 트랜잭션을 포함하는 서스펜스
파일
기능 점수 분석 (Function Point Analysis)
32
데이터 기능의 유형: EIF

정의: EIF는 어플리케이션에 의해 참조되지만 상이한
어플리케이션의 경계 내에서 유지되는 논리적으로
관련된 데이터나 제어 정보로 사용자가 식별 가능한
그룹
» 의미: 기능 점수를 계산 중인 어플리케이션의 하나 이상의
기본적인 프로세스를 통해 참조되는 데이터
» 사용자가 식별 가능하다는 것은 사용자와 소프트웨어 개발자
모두가 이해하고 동의한 요구사항, 데이터 그룹
– 예: financial application의 checking account record는 관계 없는
데이터를 검증하는 동안에만 읽힘
기능 점수 분석 (Function Point Analysis)
33
데이터 기능의 유형: EIF (계속)

정의
» 논리적으로 관련된다는 것은 각 그룹이 논리적으로 적합해야
한다는 요구조건
–
–
–
–
EIF는 다른 EIF에 종속되거나 한정되지 않아야 함
성능이나 구현 상의 이유로 생성된 그룹들은 합병되어야 함
제2정규형이나 제3정규형의 엔터티 타입
데이터 흐름도(Data Flow Diagram)의 데이터 저장소(Data
Store)에 해당
– 예: 주소 테이블은 고객 파일, 거래 파일, 재고품 위치 파일, 직원
파일과 같은 논리적 그룹에 속함
기능 점수 분석 (Function Point Analysis)
34
데이터 기능의 유형: EIF (계속)

정의
» 데이터는 또 다른 어플리케이션 내에서 유지되는 사실(facts),
수(figures) 등의 모임
– check number, amount, date, payee, memo entry, account
number는 checking account record 내에 유지됨
» 제어 정보는 어플리케이션의 기본 프로세스에 영향을 주기
위해 어플리케이션에 의해 이용되는 데이터
– 어떤 데이터가 언제 어떻게 처리되는지를 규정
– 예: Printer Manager 내에 유지되는 제어 데이터는
PowerPoint에 의해 읽힘, 부정확하거나 부적절한 데이터를
거부하기 위한 편집 데이터의 참조, 이벤트의 순서와 타이밍을
설정하는 날짜와 시간이 읽히거나 참조, 이벤트를 제어하기
위한 threshold의 설정
기능 점수 분석 (Function Point Analysis)
35
데이터 기능의 유형: EIF (계속)

정의
» 유지(maintain)된다는 것은 어플리케이션의 기본 프로세스
동안 데이터가 수정된다는 사실을 의미
» 기본 프로세스는 사용자에게 의미 있는 가장 작은 작업 단위
– 창고에서 물건의 스크린 디스플레이는 다양한 서브 프로세스로
분할 될 수 있으나, 물건의 양을 판단하기 위해 하나의 파일이
읽히고 별도의 파일은 물건의 내역을 참조하기 위해 읽힘
– 창고에서 물건을 출하(issue)하는 것은 기본 프로세스
– 동일 트랜잭션으로 여러 EIF 갱신 가능
기능 점수 분석 (Function Point Analysis)
36
IFPUG의 EIF 계산 규칙




데이터나 제어 정보의 그룹은 논리적이고 사용자가 식별 가능
데이터 그룹은 계산 중인 어플리케이션에 의해 참조되지만,
외부에 있음
데이터 그룹은 계산 중인 어플리케이션에 의해 유지되지 않음
데이터 그룹은 또 다른 어플리케이션에 의해 유지됨
» 데이터 그룹이 어플리케이션 내에서 일단 EIF로 식별되고 나면,
비록 다른 트랜잭션에 의해 참조 목적으로 이용된다고 해도, 동일한
어플리케이션 내에서 또 다시 EIF로 계산될 수 없음
기능 점수 분석 (Function Point Analysis)
37
EIF의 공통적인 예






다른 어플리케이션에서 추출되고 읽히는 데이터
어플리케이션 외부에서 유지되는 보안(security) 데이터 혹은
패스워드 데이터
어플리케이션 외부에서 유지되는 HELP 데이터
어플리케이션 외부에서 유지되는 Edit 데이터
어플리케이션 외부에서 유지되는 Parameter 데이터
어플리케이션 외부에서 유지되는 에러 파일과 에러
기술(description)
기능 점수 분석 (Function Point Analysis)
38
EIF로 잘못 식별되는 예

하나 이상의 ILF를 유지하는 또 다른 어플리케이션에서 계산
중인 어플리케이션 내부로 수신된 데이터
» 트랜잭션 데이터로 간주되어 EI로 계산되어야 함

계산 중인 어플리케이션에 의해 유지되지만, 상이한
어플리케이션에 의해 접근되고 이용되는 데이터
» 상이한 어플리케이션에 대한 EIF로 계산되어야 함

계산 중인 어플리케이션에 의해 포맷되어 다른
어플리케이션으로 송신되는 데이터
» EO나 EQ로 계산되어야 함



임시 파일이나 동일한 파일의 다양한 반복
작업 파일
정렬 파일
기능 점수 분석 (Function Point Analysis)
39
EIF로 잘못 식별되는 예 (계속)

디스플레이나 프린트에 앞서서 다른 ILF나 EIF에서 추출된
데이터를 포함하는 extract file 혹은 view file
» EO나 EQ를 생성하는데 필요한 파일의 일부




기술적인 이유로 도입된 파일
동일한 파일의 사본
별도로 유지되는 대치 색인(alternative index), 조인(join),
관계(relationship)
감사(audit) 데이터나 이력 데이터
» 어플리케이션 트랜잭션 데이터에서 함께 계산되어야 함
기능 점수 분석 (Function Point Analysis)
40
ILF와 EIF의 복잡도

ILF와 EIF의 개수와 각각의 기능 복잡도가 함께 기능 점수의
계산에 영향을 미친다. 식별된 각각의 ILF 와 EIF는 관련된
데이터 요소 타입(DET)과 레코드 요소 타입(RET)의 수를
기준으로 기능 복잡도가 결정된다.
» 기능 복잡도(functional complexity)는 DET와 RET의 개수에 따라
low, average, high 중 하나의 등급을 부여함 (복잡도 행렬에 정의)
» 데이터 요소 타입(DET)은 사용자가 인식 가능한, 유일하고,
반복되지 않는 필드나 속성
» 레코드 요소 타입(RET)은 ILF나 EIF 내에 포함된 데이터 요소들로
사용자가 인식 가능한 서브 그룹 (optional이나 mandatory)
– 서브 그룹은 ER 다이어그램에서 엔터티 서브 타입이나 속성 엔터티로
표현됨
기능 점수 분석 (Function Point Analysis)
41
IFPUG의 DET 계산 규칙

ILF나 EIF에서 유지되거나 검색되는 필드로, 사용자가 유일하게
식별 가능한 필드 각각에 대해 하나의 DET로 계산한다.
» 예: checking account record에서 유지되는 check number, amount,
date, payee, memo entry, account number는 각각 유일한 필드로
각각 하나의 DET로 계산됨

둘 이상의 어플리케이션이 DET를 제외하고는 동일한 ILF나
EIF를 유지, 참조할 때에는 각 어플리케이션이 이용하는
DET만을 계산한다.
» counting example: A(8), B(7), C(2)

다른 ILF나 EIF와의 관계를 설정하기위해 필요한 각 데이터는
하나의 DET로 계산한다.
» 외래 키
기능 점수 분석 (Function Point Analysis)
42
DET counting example
기능 점수 분석 (Function Point Analysis)
43
DET에 관한 추가적인 정보


기술이나 구현상의 이유 때문에 ILF나 EIF 내에서 여러 번
나타나는 필드는 오직 한 번만 계산됨
포맷이 동일한 반복 필드는 ILF나 EIF 내에서 오직 한 번만
계산됨
» 12개의 월간 합계 필드와 하나의 년간 합계 필드는 두 개의 DET로
계산


이벤트가 발생한 시간을 기록하는 타임 스탬프는 하나의 DET로
계산됨
외부 입력(EI)을 처리하는 동안 내부에서 처리되어
데이터베이스에 저장되는 계산(calculation)은 하나의 DET로
간주됨
기능 점수 분석 (Function Point Analysis)
44
IFPUG의 RET 계산 규칙

ILF나 EIF의 선택적인 서브 그룹이나 필수적인 서브 그룹 각각을
하나의 RET로 계산한다.
» 헤더, 트레일러, 별도의 텍스트 파일과 같이 활용되는 기술이나
방법론 때문에 존재하는 임의의 RET는 계산하지 않음
» 종종 둘 이상의 서브 그룹이 동일한 논리 파일(ILF 혹은 EIF)에 속함
» 이러한 RET들은 데이터의 저장과 논리 파일간의 관계를 생성하기
위해 이용되는 2차 키의 존재로 식별 가능
» 논리 파일의 데이터는 전형적으로 제3정규형의 데이터

만일 서브 그룹이 존재하지 않으면, ILF나 EIF를 하나의 RET로
계산한다.
기능 점수 분석 (Function Point Analysis)
45
ILF나 EIF의 계산 예: 요구사항

직원 정보를 유지, 조회, 기록하는 기능이 필요. 생성된 리포트는
다른 어플리케이션에 의해 유지되는 파일에서 얻은 직원에 대한
위치 데이터를 포함.

업무 기술(job description)을 포함하는 업무 정보를 유지, 조회,
기록하는 기능이 필요.

직원에 대한 업무 배정(job assignment)을 유지, 조회, 기록하는
기능이 필요.

회사 내의 특정 위치에 있는 직원의 리스트를 포함한 위치
데이터(location data)에서 위치를 조회하고 기록하는 기능이
필요. 이 위치 데이터는 읽을 수만 있고 다른 어플리케이션에
의해서 유지됨.
기능 점수 분석 (Function Point Analysis)
46
ILF나 EIF의 계산 예: 프로세스 모델
EMPLOYEE-MAINTENANCE
CREATE-EMPLOYEE
EMPLOYEE-INQUIRY
UPDATE-EMPLOYEE
DELETE-EMPLOYEE
EMPLOYEE-REPORT
JOB-MAINTENANCE
CREATE-JOB
JOB-INQUIRY
UPDATE-JOB
DELETE-JOB
JOB-REPORT
기능 점수 분석 (Function Point Analysis)
47
프로세스 모델 (계속)
JOB-ASSIGNMENT-MAINTENANCE
ASSIGN-EMPLOYEE-TO-JOB
JOB-ASSIGNMENT-INQUIRY
TRANSFER-EMPLOYEE
EVALUATE-EMPLOYEE
DELETE-ASSIGNMENT
JOB-ASSIGNMENT-REPORT
LOCATION-REPORTING
LOCATION-INQUIRY
LOCATION-REPORT
기능 점수 분석 (Function Point Analysis)
48
ILF나 EIF의 계산 예: ER 다이어그램
EMPLOYEE
SALARIED_EMP
JOB_ASSIGNMENT
HOURLY_EMP
JOB
LOCATION
JOB_DESCRIPTION
기능 점수 분석 (Function Point Analysis)
49
관계형 데이터베이스 구조
NAME
JOB
EMPLOYEE
SSN
JOB_ASSIGNMENT
LOC_ASSGMT
LOCATION
JOB_DESC
기능 점수 분석 (Function Point Analysis)
50
IDMS 데이터베이스 구조
EMPLOYEE
SALARIED
HOURLY
JOB
LOCATION_
ASSGNMNT
JOB_
ASSGNMNT
JOB_
DESCRIP
LOCATION
기능 점수 분석 (Function Point Analysis)
51
IMS 데이터베이스 구조
EMPLOYEE
JOB_
ASSGNMNT
JOB
LOCATION_
ASSGNMNT
JOB_
ASSGNMNT
LOCATION
JOB_
DESCRIP
기능 점수 분석 (Function Point Analysis)
LOCATION_
ASSGNMNT
52
엔터티 타입에 포함된 필드
EMPLOYEE 엔터티 타입
Employee_Name
Social_Security_Number
Nbr_Dependents
Type_Code (Salaried 혹은 Hourly)
Location_Name (외래 키)
SALARIED_EMPLOYEE 엔터티 타입
Supervisory_Level
HOURLY_EMPLOYEE 엔터티 타입
Standard_Hourly_Rate
Collective_Bargaining_Unit_Number
JOB 엔터티 타입
Job_Name
Job_Number
Pay_Grade
기능 점수 분석 (Function Point Analysis)
53
엔터티 타입에 포함된 필드 (계속)
JOB_DESCRIPTION 엔터티 타입 (사용자를 위한 서브그룹이 아닌 오직
구현만을 위한 엔터티 타입)
Job_Number (외래 키)
Line_Number (사용자에게 중요하지 않고 오직 구현만을 위한 것)
Description_Line
JOB_ASSIGNMENT 엔터티 타입
Effective_Date
Salary
Performance_Rating
Job_Number (외래 키)
Employee_SSN (외래 키)
LOCATION 엔터티 타입
Location_Name
Address
Interoffice_Code
기능 점수 분석 (Function Point Analysis)
54
ILF나 EIF의 계산 예: 복잡도 행렬

ILF와 EIF에 관한 복잡도 행렬
기능 점수 분석 (Function Point Analysis)
55
ILF나 EIF의 계산 예: 계산 결과

EMPLOYEE는 8개의 DET와 2개의 RET를 가지는 ILF

JOB은 4개의 DET와 1개의 RET를 가지는 ILF

JOB_ASSIGNMENT는 5개의 DET와 1개의 RET를 가지는 ILF

LOCATION은 3개의 DET와 1개의 RET를 가지는 EIF
기능 점수 분석 (Function Point Analysis)
56
ILF나 EIF의 계산 예: 풀이
EMPLOYEE 엔터티 타입: ILF, 서브 그룹이 존재하므로 별도의 RET 계산 않음
Employee_Name: DET 1
Social_Security_Number : DET 2
Nbr_Dependents: DET 3
Type_Code (Salaried 혹은 Hourly) : DET 4
Location_Name (외래 키): DET5
SALARIED_EMPLOYEE 엔터티 타입: EMPLOYEE 내의 RET 1
Supervisory_Level: DET 6
HOURLY_EMPLOYEE 엔터티 타입: EMPLOYEE 내의 RET 2
Standard_Hourly_Rate : DET 7
Collective_Bargaining_Unit_Number: DET 8
JOB 엔터티 타입: ILF, RET 1
Job_Name: DET 1
Job_Number : DET 2
Pay_Grade: DET 3
기능 점수 분석 (Function Point Analysis)
57
ILF나 EIF의 계산 예: 풀이
JOB_DESCRIPTION 엔터티 타입: 구현상의 이유로만 존재하는 JOB의 일부
Job_Number (외래 키): 이전에 DET 2로 계산됨
Line_Number : 구현상의 이유로만 존재
Description_Line: DET 4
JOB_ASSIGNMENT 엔터티 타입: ILF, RET 1, 자신의 속성을 가지고 별도로 유지됨
Effective_Date : DET 1
Salary : DET 2
Performance_Rating : DET 3
Job_Number (외래 키) : DET 4
Employee_SSN (외래 키) : DET 5
LOCATION 엔터티 타입 : EIF, RET 1
Location_Name : DET 1
Address : DET 2
Interoffice_Code : DET 3
기능 점수 분석 (Function Point Analysis)
58
ILF나 EIF의 계산 예: 복잡도

ILF와 EIF에 관한 복잡도 행렬에 의해 3개의 low ILF, 한 개의 low EIF
기능 점수 분석 (Function Point Analysis)
59
ILF나 EIF의 계산 예: 미조정된 기능 점수

3개의 low ILF: 21, 한 개의 low EIF: 5
기능 점수 분석 (Function Point Analysis)
60
3
트랜잭션 기능의 크기 측정




트랜잭션 기능의 유형
외부 입력
외부 출력
외부 조회
기능 점수 분석 (Function Point Analysis)
61
트랜잭션 기능의 유형

트랜잭션 기능은 어플리케이션이 사용자에게 제공하는 기능을
나타냄

외부 입력(EI)은 어플리케이션 안으로 들어오는 데이터(ILF를
유지하기 위해) 혹은 제어 정보(시스템의 동작을 변경하기
위해)의 처리

외부 조회(EQ)는 ILF, EIF에서 데이터나 제어 정보의 검색을 통해
어플리케이션 밖으로 데이터를 내 보냄

외부 출력(EO)은 데이터나 제어 정보의 검색이 아닌 프로세싱
논리를 가지고 데이터를 어플리케이션 밖으로 데이터를 내 보냄
기능 점수 분석 (Function Point Analysis)
62
기능 점수 계산 과정
1. 기능 점수의 유형 결정
2. 기능 점수 계산 범위와 어플리케이션 경계를 식별
3. 데이터 기능(내부 논리 파일, 외부 인터페이스 파일)과
복잡도 계산
4. 트랜잭션 기능(외부 입력, 외부 출력, 외부 조회)과
복잡도 계산
5. 미조정된 기능 점수(unadjusted function point) 계산
6. 일반 시스템 특성에 근거한 값 조정 인자 계산
7. 조정된 기능 점수(adjusted function point) 계산
기능 점수 분석 (Function Point Analysis)
63
외부 입력 (EI)

정의: EI는 어플리케이션의 경계 밖에서 안으로 들어가는
데이터나 제어 정보를 처리하는 어플리케이션의 기본
프로세스이고, 처리된 데이터는 하나 이상의 ILF를 유지하고,
제어 정보는 ILF를 유지하지 않을 수도 있음

의미: 하나 이상의 ILF를 유지하고, 프로세싱 논리를 통해
어플리케이션의 동작을 변경하는 것
기능 점수 분석 (Function Point Analysis)
64
외부 입력 (계속)

정의
» 기본 프로세스는 사용자에게 의미 있는 가장 작업 단위로,
독립적(self-contained)이어야 하고 계산 중인
어플리케이션의 비즈니스를 일관된 상태로 두어야 함
– 예 1: 직원을 추가하는 어플리케이션에서 급여나 부양 가족과
같은 부분 정보를 추가하는 것은 사용자 관점의 기본
프로세스가 아니고, 일부 정보만을 추가하면 어플리케이션의
비즈니스가 비일관된 상태로 남게 됨
– 예 2: 세 개의 화면으로 구성되는 고용 보험 입력에서 기본
프로세스는 세 화면 모두를 완성하는 것을 요구면, 한 화면의
필드나 필드의 일부를 완성하는 것은 독립적인 프로세스가
아니고 비즈니스를 일관된 상태로 두지 않음
기능 점수 분석 (Function Point Analysis)
65
외부 입력 (계속)

정의
» 데이터는 어플리케이션에 의해 처리되는 사실(facts),
수(figures) 등의 모임
– 고용 보험에서 직원 이름, 수령인의 선택, 보험 요율
» 제어 정보는 어플리케이션의 기본 프로세스에 영향을 주기
위해 어플리케이션에 의해 이용되는 데이터
– 프로세스를 유지하거나 시작하기 위해 이용될 수 있음
– 예: 시스템을 디폴트 상태로 유지하기 위한 제어 데이터, 실시간
시스템에서 센서나 기구 혹은 다른 어플리케이션으로부터
발생하는 시그널
기능 점수 분석 (Function Point Analysis)
66
외부 입력 (계속)

정의
» 유지(maintain)한다는 것은 어플리케이션의 기본 프로세스
동안 데이터를 수정하는 능력을 의미
– 예: add, change, delete, populate, revise, update, assign, save
as, create
– 트랜잭션은 기본 프로세스이고, 전체 프로세스를 구성하지
않는 변경, 삭제, 라인의 저장 등은 계산하지 않음
» 프로세싱 논리(processing logic)는 사용자가 기본 프로세스를
완성하기 위해 특별하게 요청하는 요구사항
– 대개 프로세싱 논리의 조합이 기본 프로세스를 완성하기 위해
요구됨

예: EI의 기본 프로세스가 다중 검증, 필터, 재정렬 등을 포함
– 프로세싱 논리 자체가 EI, EO, EQ의 유일성을 결정하지않음

재정렬이 트랜잭션의 유일성을 결정하지 않음
기능 점수 분석 (Function Point Analysis)
67
EI의 프로세싱 논리의 예













검증(validations)
수학식이나 계산
동등한 값으로의 변환
여러 데이터 값을 비교하기 위한 데이터의 필터링과 선택
적용 가능한 것을 결정하기 위한 조건 분석
ILF의 갱신
ILF나 EIF의 참조
데이터나 제어 정보의 검색
유도된 데이터의 생성
시스템 동작의 변경
경계 밖에서의 정보의 준비와 프리젠테이션
어플리케이션 경계 안으로 들어가는 데이터나 제어 정보를 받는 기능
데이터 집합의 재정렬이나 재배열
기능 점수 분석 (Function Point Analysis)
68
IFPUG의 EI 데이터 계산 규칙





데이터는 어플리케이션 경계 밖으로부터 수신되어야 한다.
어플리케이션의 기본 프로세스를 통해 ILF에 있는 최소한
하나의 데이터가 유지되어야 한다.
프로세스는 사용자에게 의미 있는 가장 작업 작업 단위이어야
한다.
프로세스는 독립적이어야 하고 기능 점수를 계산하는
어플리케이션의 비즈니스를 일관된 상태로 두어야 한다.
식별된 프로세스에 대해 다음 규칙 중 하나가 적용되어야 한다.
1.
2.
3.
프로세싱 논리는 유일하거나 다른 외부 입력에 의해 수행되는
프로세싱 논리와 상이해야 한다.
데이터 요소의 집합은 다른 외부 입력에 관해 식별된 집합과
상이해야 한다.
참조되는 ILF나 EIF는 다른 외부 입력에 의해 참조되는 것들과
상이해야 한다.
기능 점수 분석 (Function Point Analysis)
69
IFPUG의 EI 트랜잭션 계산 규칙





제어 정보는 어플리케이션 경계 밖으로부터 수신되어야 한다.
제어 정보는 어플리케이션의 요구사항을 준수하는지를
보장하기 위해 사용자에 의해 명세화되어야 한다.
프로세스는 사용자에게 의미 있는 가장 작업 작업 단위이어야
한다.
프로세스는 독립적이어야 하고 기능 점수를 계산하는
어플리케이션의 비즈니스를 일관된 상태로 두어야 한다.
식별된 프로세스에 대해 다음 규칙 중 하나가 적용되어야 한다.
1.
2.
3.
프로세싱 논리는 유일하거나 다른 외부 입력에 의해 수행되는
프로세싱 논리와 상이해야 한다.
데이터 요소의 집합은 다른 외부 입력에 관해 식별된 집합과
상이해야 한다.
참조되는 ILF나 EIF는 다른 외부 입력에 의해 참조되는 것들과
상이해야 한다.
기능 점수 분석 (Function Point Analysis)
70
EI의 추가적인 예

ILF를 유지하는데 이용되는 트랜잭션 데이터
» sale, lost item, scheduled appointment, transfer, new hire, insurance form

제어 정보를 제공하는 입력
» 예: 지진 탐지기가 지구의 움직임을 기록


처리를 요청하는 다른 어플리케이션에서 온 메시지
다른 어플리케이션으로부터의 트랜잭션 파일
» 현금 판매와 신용 카드 거래와 같이 별도의 처리를 요구하는 상이한 유형의
다중 트랜잭션 포함



ILF를 유지하는 입력
제어를 시작하거나 데이터를 입력하는 사용자 기능
이전 어플리케이션에서 유지되었으나 개발 프로젝트나 확장 프로젝트의
일부로 새로 개발되는 ILF로 데이터가 이전될 때 컨버전 노력을 통해
처리되어야 하는 데이터 파일
» 어플리케이션 기능 점수가 아닌 프로젝트 기능 점수 계산의 일부로 포함됨


처리를 시작하게 하는 물리적인 데이터
HELP, 메시지 파일, parameter 등을 포함하는 임의의 ILF의 유지보수
기능 점수 분석 (Function Point Analysis)
71
EI로 잘못 식별되는 예





어플리케이션 내에서 ILF를 유지하는데 이용되지 않고 다른
어플리케이션에 의해 읽히는 참조 데이터는 전형적인 EIF
조회나 출력의 입력 요구 측면
네비게이션이나 선택을 위해 이용되지만 ILF를 유지하지 않는
메뉴 화면
어플리케이션의 사용자 로그 온 화면
동일한 논리를 호출하는 여러 방법
» 여러 화면에서 동일한 기능이나 트랜잭션을 수행하는 두 개의 액션
키는 하나로 계산되어야 함

필드를 채우거나 데이터를 이동하기 위해 화면 상에서 데이터의
포인팅과 클릭킹
기능 점수 분석 (Function Point Analysis)
72
EI로 잘못 식별되는 예 (계속)



스크린 데이터의 다시 보기(refreshing) 혹은 취소
삭제나 임의의 다른 트랜잭션에 대해 사용자에게 확인 요청하는
메시지에 대한 응답
동일한 어플리케이션 내에서 온라인 처리와 일괄 처리 사이에
전달된 데이터
» 어플리케이션 경계를 넘지 않음

동일한 어플리케이션 내에서 클라이언트와 서버 사이에 전달된
데이터
» 어플리케이션 경계를 넘지 않음
기능 점수 분석 (Function Point Analysis)
73
EI의 복잡도

EI의 개수와 각각의 기능 복잡도가 함께 미조정된 기능 점수의
계산에 영향을 미친다. 식별된 각각의 EI는 관련된 데이터 요소
타입(DET)과 참조 파일 타입(FTR)의 수를 기준으로 기능
복잡도가 결정된다.
» 기능 복잡도(functional complexity)는 DET와 FTR의 개수에 따라
low, average, high 중 하나의 등급을 부여함 (복잡도 행렬에 정의)
» 데이터 요소 타입(DET)은 사용자가 인식 가능한, 유일하고,
반복되지 않는 필드나 속성으로 외래 키 속성을 포함
» 참조 파일 타입(FTR)은 간단하게 참조 파일이라고 부르며, EI
트랜잭션에 의해 유지되거나 읽히는 ILF와 EI 트랜잭션에 의해
읽히는 EIF의 총 개수
기능 점수 분석 (Function Point Analysis)
74
IFPUG의 DET 계산 규칙

EI의 기본 프로세스를 완성하기 위해 어플리케이션의 경계를
지나는 외래 키를 포함하여 사용자가 유일하게 식별 가능한
반복되지 않는 필드 각각에 대해 하나의 DET로 계산한다.
» 예: item number, quantity sold, date는 데이터가 어떻게 물리적으로
저장되었는지 관계 없이 각각이 sale 트랜잭션 상의 하나의 DET로
계산됨

사용자에 의해 입력되지는 않으나 (경계를 넘지 않은), EI를 통해
어플리케이션에 의해 검색되거나 유도되어 ILF에서 유지되는
필드에 대해서는 DET로 계산하지 않는다.
» 예: 시스템이 생성한 날짜, 검색된 값, 구좌 번호, 계산된 값
기능 점수 분석 (Function Point Analysis)
75
IFPUG의 DET 계산 규칙 (계속)

주소 라인처럼 물리적으로는 여러 필드로 저장되었으나, 단일 정보로
사용자가 요구하는 논리적 필드는 하나의 DET로 계산한다.

처리 동안 에러가 발생했음을 나타내거나, 처리가 완료되었음을
확인하거나, 처리가 계속되어야 함을 증명하기 위해 어플리케이션의
경계 밖으로 시스템 응답 메시지를 전송하는 기능에 대해 하나의 DET로
계산한다.
» 여러 메시지가 존재함에도 불구하고 메시지 전체를 하나의 DET로 계산

동일한 논리를 호출하는 여러 방법이 존재하더라 EI의 액션을 명세하는
기능에 대해 하나의 DET로 계산한다.
» EI의 동일한 액션에 대한 명령어나 기능 키를 함께 하나의 DET로 계산
기능 점수 분석 (Function Point Analysis)
76
IFPUG의 FTR 계산 규칙

EI의 기본 프로세스에 의해 유지되는 각 ILF에 대해서 하나의
FTR로 계산한다.

EI의 처리 동안 읽히는 내부 논리 파일(ILF)이나 외부 인터페이스
파일(EIF) 각각에 대해서 하나의 FTR로 계산한다.

EI에 의해 유지되고 읽히는 각 ILF에 대해서 오직 하나의 FTR로
계산한다.
기능 점수 분석 (Function Point Analysis)
77
EI의 계산 예: 요구사항

직원 정보를 유지, 조회, 기록하는 기능이 필요. 생성된 리포트는
다른 어플리케이션에 의해 유지되는 파일에서 얻은 직원에 대한
위치 데이터를 포함.

업무 정보를 유지, 조회, 기록하는 기능이 필요. 업무 기술(Job
Description)은 80 문자 단위의 라인들로 구성되고, 이 정보는
업무(Job)와 독립적으로 유지되지 않음.

직원에 대한 업무 배정(Job Assignment)을 유지, 조회, 기록하는
기능이 필요.

회사 내의 특정 위치에 있는 직원의 리스트를 포함한 위치
데이터(Location Data)에서 위치를 조회하고 기록하는 기능이
필요. 이 위치 데이터는 읽을 수만 있고 다른 어플리케이션에
의해서 유지됨.
기능 점수 분석 (Function Point Analysis)
78
EI의 계산 예: 프로세스 모델
EMPLOYEE-MAINTENANCE
CREATE-EMPLOYEE
EMPLOYEE-INQUIRY
UPDATE-EMPLOYEE
DELETE-EMPLOYEE
EMPLOYEE-REPORT
JOB-MAINTENANCE
CREATE-JOB
JOB-INQUIRY
UPDATE-JOB
DELETE-JOB
JOB-REPORT
기능 점수 분석 (Function Point Analysis)
79
프로세스 모델 (계속)
JOB-ASSIGNMENT-MAINTENANCE
ASSIGN-EMPLOYEE-TO-JOB
JOB-ASSIGNMENT-INQUIRY
TRANSFER-EMPLOYEE
EVALUATE-EMPLOYEE
DELETE-ASSIGNMENT
JOB-ASSIGNMENT-REPORT
LOCATION-REPORTING
LOCATION-INQUIRY
LOCATION-REPORT
기능 점수 분석 (Function Point Analysis)
80
ILF와 EIF의 계산 결과
EMPLOYEE 엔터티 타입: ILF, 서브 그룹이 존재하므로 별도의 RET 계산 않음
Employee_Name: DET 1
Social_Security_Number : DET 2
Nbr_Dependents: DET 3
Type_Code (Salaried 혹은 Hourly) : DET 4
Location_Name (외래 키): DET5
SALARIED_EMPLOYEE 엔터티 타입: EMPLOYEE 내의 RET 1
Supervisory_Level: DET 6
HOURLY_EMPLOYEE 엔터티 타입: EMPLOYEE 내의 RET 2
Standard_Hourly_Rate : DET 7
Collective_Bargaining_Unit_Number: DET 8
JOB 엔터티 타입: ILF, RET 1
Job_Name: DET 1
Job_Number : DET 2
Pay_Grade: DET 3
기능 점수 분석 (Function Point Analysis)
81
ILF와 EIF의 계산 결과
JOB_DESCRIPTION 엔터티 타입: 구현상의 이유로만 존재하는 JOB의 일부
Job_Number (외래 키): 이전에 DET 2로 계산됨
Line_Number : 구현상의 이유로만 존재
Description_Line: DET 4
JOB_ASSIGNMENT 엔터티 타입: ILF, RET 1, 자신의 속성을 가지고 별도로 유지됨
Effective_Date : DET 1
Salary : DET 2
Performance_Rating : DET 3
Job_Number (외래 키) : DET 4
Employee_SSN (외래 키) : DET 5
LOCATION 엔터티 타입 : EIF, RET 1
Location_Name : DET 1
Address : DET 2
Interoffice_Code : DET 3
기능 점수 분석 (Function Point Analysis)
82
ILF와 EIF의 복잡도 계산 결과

ILF와 EIF에 관한 복잡도 행렬에 의해 3개의 low ILF, 한 개의 low EIF
기능 점수 분석 (Function Point Analysis)
83
EI의 계산 예: 복잡도 행렬
기능 점수 분석 (Function Point Analysis)
84
EI의 계산 예: DET에 관한 가정

각 입력 트랜잭션이 에러 메시지 (에러 메시지에 대해 하나의
DET로 계산)를 리턴하고, 최소한 하나의 명령 키(각 EI에 대해
다른 DET로 계산)를 가짐.

생성 기능과 갱신 기능은 특정 ILF의 모든 필드를 액세스 하지만,
삭제 기능은 기본 키만을 액세스.

배정(assign) 기능과 전보(transfer) 기능은 Performance_Rating
필드를 액세스 하지 않으며, 평가(evaluate) 기능은 Salary 필드를
액세스 하지 않음.

각 트랜잭션에 대해 에러 메시지와 명령 키인 추가적인 두 개의
DET를 계산.
기능 점수 분석 (Function Point Analysis)
85
EI의 계산 예: FTR에 관한 가정

유지되는 ILF와 편집 목적으로 참조해야 하는 다른 ILF 혹은
EIF를 계산해야 함.

Employee를 생성할 때 EMPLOYEE와 LOCATION이라는 두
개의 FTR을 가짐.

Employee를 삭제할 때 EMPLOYEE를 유지하고
JOB_ASSIGNMENT를 참조하거나 갱신.
기능 점수 분석 (Function Point Analysis)
86
EI의 계산 예: DET와 FTR
EMPLOYEE-MAINTENANCE
CREATE-EMPLOYEE: DET 10, FTR 2(EMPLOYEE, LOCATION)
UPDATE-EMPLOYEE: DET 10, FTR 2(EMPLOYEE, LOCATION)
DELETE-EMPLOYEE: DET 3, FTR 2(EMPLOYEE,JOB_ASSIGNMENT)
JOB-MAINTENANCE
CREATE-JOB: DET 6, FTR 1(JOB)
UPDATE-JOB: DET 6, FTR 1(JOB)
DELETE-JOB: DET 3, FTR 2(JOB, JOB_ASSIGNMENT)
JOB-ASSIGNMENT-MAINTENANCE
ASSIGN_EMPLOYEE-TO-JOB: DET 6, FTR 3(EMPLOYEE,
JOB, JOB_ASSIGNMENT
TRANSFER-EMPLOYEE: DET 6, FTR 3(EMPLOYEE, JOB, JOB_ASSIGNMENT)
EVALUATE-EMPLOYEE: DET 6, FTR 1(JOB_ASSIGNMENT)
DELETE-ASSIGNMENT: DET 4, FTR 1(JOB_ASSIGNMENT)
기능 점수 분석 (Function Point Analysis)
87
EI의 계산 예: 복잡도 행렬

6개의 low EI, 두 개의 average EI(create update), 두 개의 high
EI(assign, transfer)
기능 점수 분석 (Function Point Analysis)
88
EI의 계산 예: 미조정된 기능 점수

6개의 low EI, 두 개의 average EI(create update), 두 개의 high
EI(assign, transfer)

미조정된 기능 점수는 38
기능 점수 분석 (Function Point Analysis)
89
외부 출력 (EO)

정의: EO는 어플리케이션의 경계 밖으로 나가는 데이터나 제어
정보를 생성하는 어플리케이션의 기본 프로세스이다. 그 의미는
데이터나 제어 정보의 검색이 아닌 프로세싱 논리(processing
logic)를 통해 사용자에게 정보를 제시하는 것이다. 프로세싱
논리는 최소한 하나의 수학식이나 계산을 포함해야 하고, 유도된
데이터를 생성하고, 하나 이상의 ILF를 유지하고, 혹은 시스템의
동작(behavior)을 변경하는 것이다.
기능 점수 분석 (Function Point Analysis)
90
외부 출력 (계속)

정의
» 기본 프로세스는 사용자에게 의미 있는 가장 작업 단위로,
독립적(self-contained)이어야 하고 계산 중인
어플리케이션의 비즈니스를 일관된 상태로 두어야 함
– 예 : 여러 페이지로 구성된 리포트는 하나의 EO로만 계산됨
» 데이터는 출력 트랜잭션에 의해 처리되는 사실(facts),
수(figures) 등의 모임
– 예: 위의 리포트 트랜잭션에 포함된 데이터 필드(department
name, department number, address, month, total monthly
sales, total monthly purchases, current running total for the
year)
기능 점수 분석 (Function Point Analysis)
91
외부 출력 (계속)

정의
» 제어 정보는 어플리케이션의 기본 프로세스에 영향을 주기
위해 어플리케이션에 의해 이용되는 데이터
– 어플리케이션에 의해 사용자나 다른 어플리케이션에게 송신됨
– 예: 사용자가 명세한 기능 요구사항을 준수하는지 보증하기
위해 송신되는 데이터로, 특정 내부 조건이 설정되었음을
알리는 메시지 포함 가능
– 예: 실시간 시스템에서의 alarm, 메시지, 생산 라인의 중단
통보와 같은 outgoing 시그널
» 유도된 데이터는 추가적인 데이터를 생성하기 위해 기본
데이터의 변환을 통해 생성
– 하나 이상의 ILF, EIF로부터 정보의 직접적인 검색, 컨버전,
편집이 아닌 프로세싱을 요구
기능 점수 분석 (Function Point Analysis)
92
외부 출력 (계속)

정의
» 유지는 기본 프로세스를 통해 데이터를 수정하는 능력
– payroll check를 생성하는 동안 ILF에 수표 번호를 자동적으로
입력
» 프로세싱 논리(processing logic)는 기본 프로세스를 완성하기
위해 사용자에 의해 특별하게 요청되는 요구사항
– 대개 프로세싱 논리의 조합이 기본 프로세스를 완성하기 위해
요구됨

예: EO의 기본 프로세스가 다중 검증, 필터, 재정렬 등을 포함
– 프로세싱 논리 자체가 EI, EO, EQ의 유일성을 결정하지 않음

재배열, 재포맷팅, 재정렬이 유일한 프로세싱 논리가 아님
기능 점수 분석 (Function Point Analysis)
93
EO의 프로세싱 논리의 예













검증(validations)
수학식이나 계산
동등한 값으로의 변환
여러 데이터 값을 비교하기 위한 데이터의 필터링과 선택
적용 가능한 것을 결정하기 위한 조건 분석
ILF의 갱신
ILF나 EIF의 참조
데이터나 제어 정보의 검색
유도된 데이터의 생성
시스템 동작의 변경
경계 밖에서의 정보의 준비와 프리젠테이션
어플리케이션 경계 안으로 들어가는 데이터나 제어 정보를 받는 기능
데이터 집합의 재정렬이나 재배열
기능 점수 분석 (Function Point Analysis)
94
IFPUG의 EO 계산 규칙


데이터나 제어 정보는 어플리케이션 경계 밖으로 송신되어야
한다.
EO의 기본 프로세스의 프로세싱 논리는 다음 중 하나를
만족해야 한다.
1. 최소한 하나의 수학식이나 계산을 포함
2. 유도된 데이터의 생성
3. 최소한 하나의 ILF의 유지
4. 어플리케이션의 동작을 변경


프로세스는 사용자에게 의미 있는 가장 작업 작업 단위이어야
한다.
프로세스는 독립적이어야 하고 기능 점수를 계산하는
어플리케이션의 비즈니스를 일관된 상태로 두어야 한다.
기능 점수 분석 (Function Point Analysis)
95
IFPUG의 EO 계산 규칙 (계속)

식별된 프로세스에 대해 다음 규칙 중 하나가 적용되어야 한다.
1.
2.
프로세싱 논리는 유일하거나 다른 외부 출력에 의해 수행되는
프로세싱 논리와 상이해야 한다.
데이터 요소의 집합은 다른 외부 출력에 관해 식별된 집합과
상이해야 한다.


3.
동일한 필드에서 상이한 데이터를 가지는 개개인에 관해서 생성된
account statement는 하나의 EO
상세한 수준과 개략적인 수준에서 각각 별도로 생성된 두 리포트는
유일한 프로세싱 논리와 계산을 가지므로 두 개의 EO로 계산됨
참조되는 ILF나 EIF는 다른 외부 입력에 의해 참조되는 것들과
상이해야 한다.
기능 점수 분석 (Function Point Analysis)
96
EO의 추가적인 예




알고리즘이나 계산이 필요한 리포트
데이터가 갱신되거나 유도될 때 혹은 기본 프로세스의 일부로 갱신될 때
다른 어플리케이션으로 송신되는 데이터, 파일, 메시지
생성시에 check number와 check report를 동시에 갱신하는 check
개발 프로젝트나 확장 프로젝트의 부분으로서 데이터가 이전될 때
컨버전 노력의 합계를 기록하는 컨버전 리포트
» 어플리케이션 기능 점수가 아닌 프로젝트 기능 점수 계산의 일부로 포함됨






화면 상에 표시되거나 파일에 전달되는 유도된 정보 혹은 계산된 정보
계산을 필요로 하는 막대 그래프와 파이 챠트
전화로 전달되는 계산된 응답
사용자에게 전달되거나 무기시스템에서 다른 어플리케이션으로
전달되는 무기 발사 정보
현재까지의 사용액이 계산된 신용카드 분실 기록
제안된 보험 요율의 계산
기능 점수 분석 (Function Point Analysis)
97
EO로 잘못 식별되는 예


부서별 리포트와 같이 상이한 데이터 값을 가지는 동일한 리포트
데이터를 보내는 어플리케이션 내에서 식, 계산, 유도된 데이터를
가지지 않고 ILF를 유지하지 않는 리포트
» 대부분 EQ

상세한 리포트에 포함된 요약 필드
» 상세 리포트는 EO

데이터를 보내는 어플리케이션 내에서 식, 계산, 유도된 데이터를
가지지 않고 ILF를 유지하지 않는 다른 어플리케이션으로 보내지는 파일
» 대부분 EQ




프로세싱 논리가 동일한 다중 미디어
스크린 데이터의 다시 보기나 취소
다른 프로세싱 논리가 없는 데이터 집합의 재정렬이나 재배열
다른 어플리케이션에 의해 읽히지만, 기능 점수가 계산되는
어플리케이션에 저장된 참조 데이터
» 계산되는 어플리케이션에 의해 EO로 처리되지 않음
기능 점수 분석 (Function Point Analysis)
98
EO로 잘못 식별되는 예 (계속)


조회나 출력의 입력 요구 측면
HELP
» 대부분 EQ로 계산








시스템 로그 오프
동일한 출력 프로세스를 호출하는 여러 방법
EI의 편집이나 검증 혹은 EO나 EQ의 요구 측면의 결과로 나오는 에러
메시지
데이터가 처리 되었음을 확인하는 확인 메시지
둘 이상의 어플리케이션으로 보내지는 동일한 데이터
SQL이나 FOCUS와 같은 언어의 사용을 통해 사용자가 지시하고
제어하는 특별한 리포트
어플리케이션 경계를 넘지 않고 동일한 어플리케이션 내에서 온라인과
일괄 처리 사이에 전달된 데이터
어플리케이션 경계를 넘지 않고 동일한 어플리케이션 내에서
클라이언트와 서버 사이에 전달된 데이터
기능 점수 분석 (Function Point Analysis)
99
EO의 복잡도

EO의 개수와 각각의 기능 복잡도가 함께 미조정된 기능 점수의
계산에 영향을 미친다. 식별된 각각의 EO는 관련된 데이터 요소
타입(DET)과 참조 파일 타입(FTR)의 수를 기준으로 기능
복잡도가 결정된다.
» 기능 복잡도(functional complexity)는 DET와 FTR의 개수에 따라
low, average, high 중 하나의 등급을 부여함 (복잡도 행렬)
» 데이터 요소 타입(DET)은 대개 어플리케이션의 경계를 넘고
사용자가 인식 가능한, 유일하고, 반복되지 않는 필드나 속성
» 참조 파일 타입(FTR)은 간단하게 참조 파일이라고 부르며, EO
트랜잭션에 의해 유지되거나 읽히는 ILF와 EO 트랜잭션에 의해
읽히는 EIF의 총 개수
기능 점수 분석 (Function Point Analysis)
100
IFPUG의 DET 계산 규칙

어플리케이션의 경계를 들어가고, 무슨 데이터가 언제 어떻게 기본
프로세스에 의해 검색, 생성되는가를 명세하는데 필요하고 사용자가
유일하게 식별 가능한 반복되지 않는 필드 각각에 대해 하나의 DET로
계산한다.
» 종종 제어 정보, 선택 정보, 프로세싱 매개변수로 고려

어플리케이션의 경계를 나가고, 사용자가 유일하게 식별 가능한
반복되지 않는 필드 각각에 대해 하나의 DET로 계산한다.
» 외래 키 속성과 제어 정보

만일 하나의 DET가 경계를 모두 들어오고 나가면, 기본 프로세스에
대해 단지 하나로만 계산
기능 점수 분석 (Function Point Analysis)
101
IFPUG의 DET 계산 규칙 (계속)

처리 동안 에러가 발생했음을 나타내거나, 처리가 완료되었음을
확인하거나, 처리가 계속되어야 함을 증명하기 위해 어플리케이션의
경계 밖으로 시스템 응답 메시지를 전송하는 기능에 대해 하나의 DET로
계산한다.
» 여러 메시지가 존재하더라도 메시지 전체를 하나의 DET로 계산

동일한 논리 프로세스를 호출하는 여러 방법이나 다중 키가
존재하더라도 EO의 액션을 명세하는 기능에 대해 하나의 DET로
계산한다.
» OK 버튼, 기능 키, 액션 키, 마우스 클릭

페이지 번호, 위치 정보(행과 열), 페이지 명령(이전, 다음), 날짜/시간
필드를 포함하는 페이지 변수나 시스템이 생성하는 스탬프는 계산하지
않는다.
» DET는 검색된 날짜를 포함하나 리포트 인쇄 날짜와 같은 시스템 생성
날짜는 포함하지 않음
기능 점수 분석 (Function Point Analysis)
102
IFPUG의 DET 계산 규칙 (계속)

리포트 제목, 스크린 ID, 열 표제(column heading), 필드 제목을
포함하는 리터럴은 계산하지 않는다.

물리적으로는 여러 필드로 저장되었지만 사용자에 의해 단일 정보로
요구되는 논리적 필드에 대해서는 하나의 DET로 계산한다.
» 세 개의 필드로 저장되나 하나의 정보로 사용되는 날짜나 이름은 각각
하나의DET로 계산됨

그래픽 디스플레이에서 각 유형의 레이블과 동등한 각 수치에 대해 각각
하나의 DET로 계산한다.
» 예: 파이 챠트는 두 개의 DET (범주, 백분율)

단일 단어, 문장, 단락, 여러 단락으로 구성될 수 있는 텍스트 정보에
관해 하나의 DET로 계산한다.
기능 점수 분석 (Function Point Analysis)
103
IFPUG의 FTR 계산 규칙

EO의 처리 동안 읽히는 내부 논리 파일(ILF)이나 외부
인터페이스 파일(EIF) 각각에 대해서 하나의 FTR로 계산한다.

EO의 기본 프로세스에 의해 유지되는 각 ILF에 대해서 하나의
FTR로 계산한다.

EO에 의해 유지되고 읽히는 각 ILF에 대해서 오직 하나의 FTR로
계산한다.
기능 점수 분석 (Function Point Analysis)
104
EO의 계산 예: 요구사항

직원 정보를 유지, 조회, 기록하는 기능이 필요. 생성된 리포트는
다른 어플리케이션에 의해 유지되는 파일에서 얻은 직원에 대한
위치 데이터를 포함.

업무 정보를 유지, 조회, 기록하는 기능이 필요. 업무 기술(Job
Description)은 80 문자 단위의 라인들로 구성되고, 이 정보는
업무(Job)와 독립적으로 유지되지 않음

직원에 대한 업무 배정(Job Assignment)을 유지, 조회, 기록하는
기능이 필요.

회사 내의 특정 위치에 있는 직원의 리스트를 포함한 위치
데이터(Location Data)에서 위치를 조회하고 기록하는 기능이
필요. 이 위치 데이터는 읽을 수만 있고 다른 어플리케이션에
의해서 유지됨.
기능 점수 분석 (Function Point Analysis)
105
EI의 계산 예: 프로세스 모델
EMPLOYEE-MAINTENANCE
CREATE-EMPLOYEE
EMPLOYEE-INQUIRY
UPDATE-EMPLOYEE
DELETE-EMPLOYEE
EMPLOYEE-REPORT
JOB-MAINTENANCE
CREATE-JOB
JOB-INQUIRY
UPDATE-JOB
DELETE-JOB
JOB-REPORT
기능 점수 분석 (Function Point Analysis)
106
프로세스 모델 (계속)
JOB-ASSIGNMENT-MAINTENANCE
ASSIGN-EMPLOYEE-TO-JOB
JOB-ASSIGNMENT-INQUIRY
TRANSFER-EMPLOYEE
EVALUATE-EMPLOYEE
DELETE-ASSIGNMENT
JOB-ASSIGNMENT-REPORT
LOCATION-REPORTING
LOCATION-INQUIRY
LOCATION-REPORT
기능 점수 분석 (Function Point Analysis)
107
ILF와 EIF의 계산 결과
EMPLOYEE 엔터티 타입: ILF, 서브 그룹이 존재하므로 별도의 RET 계산 않음
Employee_Name: DET 1
Social_Security_Number : DET 2
Nbr_Dependents: DET 3
Type_Code (Salaried 혹은 Hourly) : DET 4
Location_Name (외래 키): DET5
SALARIED_EMPLOYEE 엔터티 타입: EMPLOYEE 내의 RET 1
Supervisory_Level: DET 6
HOURLY_EMPLOYEE 엔터티 타입: EMPLOYEE 내의 RET 2
Standard_Hourly_Rate : DET 7
Collective_Bargaining_Unit_Number: DET 8
JOB 엔터티 타입: ILF, RET 1
Job_Name: DET 1
Job_Number : DET 2
Pay_Grade: DET 3
기능 점수 분석 (Function Point Analysis)
108
ILF와 EIF의 계산 결과
JOB_DESCRIPTION 엔터티 타입: 구현상의 이유로만 존재하는 JOB의 일부
Job_Number (외래 키): 이전에 DET 2로 계산됨
Line_Number : 구현상의 이유로만 존재
Description_Line: DET 4
JOB_ASSIGNMENT 엔터티 타입: ILF, RET 1, 자신의 속성을 가지고 별도로 유지됨
Effective_Date : DET 1
Salary : DET 2
Performance_Rating : DET 3
Job_Number (외래 키) : DET 4
Employee_SSN (외래 키) : DET 5
LOCATION 엔터티 타입 : EIF, RET 1
Location_Name : DET 1
Address : DET 2
Interoffice_Code : DET 3
기능 점수 분석 (Function Point Analysis)
109
ILF와 EIF의 복잡도 계산 결과

ILF와 EIF에 관한 복잡도 행렬에 의해 3개의 low ILF, 한 개의 low EIF
기능 점수 분석 (Function Point Analysis)
110
EO의 계산 예: 복잡도 행렬
기능 점수 분석 (Function Point Analysis)
111
EO의 계산 예: DET과 FTR에 관한 가정

각 리포트가 유도된 데이터나 계산된 데이터를 가지고 있는 모든
조회는 EO로 계산됨.

JOB REPORT를 제외한 각 리포트가 경계를 지나는 6개에서
19개 사이의 DET를 가짐.

Employee report는 EMPLOYEE 파일과 LOCATION 파일을 참조
» 두 파일 간의 관계(relationship) 존재.
기능 점수 분석 (Function Point Analysis)
112
EO의 계산 예: DET와 FTR
EMPLOYEE-MAINTENANCE
EMPLOYEE-REPORT: DET 6~19, FTR 2(EMPLOYEE, LOCATION)
JOB-MAINTENANCE
JOB-REPORT: DET 5, FTR 1(JOB)
JOB-ASSIGNMENT-MAINTENANCE
JOB-ASSIGNMENT-REPORT: DET 6~19, FTR 3(JOB-ASSIGNMENT,
EMPLOYEE, JOB)
LOCATION-REPORTING
LOCATION-REPORT: DET ?, FTR 2(EMPLOYEE, LOCATION) – average로 가정
기능 점수 분석 (Function Point Analysis)
113
EO의 계산 예: 복잡도 행렬

3개의 average EO(EMPLOYEE, JOB-ASSIGNMENT, LOCATION)와
한 개의 low EO(JOB)
기능 점수 분석 (Function Point Analysis)
114
EO의 계산 예: 미조정된 기능 점수

3개의 average EO와 한 개의 low EO

미조정된 기능 점수는 19
기능 점수 분석 (Function Point Analysis)
115
외부 조회 (EQ)

정의: EQ는 어플리케이션의 경계 밖으로 데이터나 제어 정보의
검색 결과를 내는 어플리케이션의 기본 프로세스이다. 그 의미는
ILF나 EIF로부터 데이터나 제어 정보의 검색을 통해 사용자에게
정보를 제시하는 것이다. 프로세싱 논리(processing logic)는
수학식이나 계산을 포함하지 않고, 유도된 데이터를 생성하지
않는다. 프로세싱 동안 ILF가 유지되지 않고, 어플리케이션의
동작(behavior)이 변경되지 않는다.
기능 점수 분석 (Function Point Analysis)
116
외부 조회 (계속)

정의
» 기본 프로세스는 사용자에게 의미 있는 가장 작업 단위로,
독립적(self-contained)이어야 하고 계산 중인
어플리케이션의 비즈니스를 일관된 상태로 두어야 함
– 예 : 검색을 위해 5개의 필드를 입력해야 하는 경우, 필드 중 하나
혹은 일부를 입력하는 것은 기본 프로세스가 아님.
– 완전한 트랜잭션이 되기 위해서는 정보의 요청, ILF나
EIF로부터 추출, 정보의 전달을 포함
» 데이터는 조회 트랜잭션에 의해 처리되는 정보의 필드
» 제어 정보는 어플리케이션의 기본 프로세스에 영향을 주는
데이터
– 어떤 데이터가 언제 어떻게 처리되는지 명세
– 그 자체가 기본 프로세스는 아님
기능 점수 분석 (Function Point Analysis)
117
외부 조회 (계속)

정의
» 프로세싱 논리(processing logic)는 기본 프로세스를 완성하기
위해 사용자에 의해 특별하게 요청되는 요구사항
– 대개 프로세싱 논리의 조합이 기본 프로세스를 완성하기 위해
요구됨

예: EQ의 기본 프로세스가 다중 검증, 필터, 재정렬 등을 포함
– 프로세싱 논리 자체가 EI, EO, EQ의 유일성을 결정하지 않음

재배열, 재포맷팅, 재정렬이 유일한 프로세싱 논리가 아님
» 유도된 데이터는 추가적인 데이터를 생성하기 위해 기본
데이터의 변환을 통해 생성
– 하나 이상의 ILF, EIF로부터 정보의 직접적인 검색, 컨버전,
편집이 아닌 프로세싱을 요구
– EQ는 유도된 데이터를 포함하지 않음
» 유지는 기본 프로세스를 통해 데이터를 수정하는 능력
– EQ는 데이터를 유지하지 않음. EI나 EO가 데이터를 유지함
기능 점수 분석 (Function Point Analysis)
118
IFPUG의 EQ 계산 규칙







데이터나 제어 정보는 어플리케이션 경계 밖으로 송신되어야
한다.
데이터나 제어 정보는 하나 이상의 ILF나 EIF로부터
검색되어야 한다.
기본 프로세스의 프로세싱 논리는 유도된 데이터를 생성하지
않아야 한다.
기본 프로세스의 프로세싱 논리는 수학식이나 계산을 포함하지
않아야 한다.
프로세스는 ILF를 유지하지 않아야 한다.
프로세스는 사용자에게 의미 있는 가장 작업 작업 단위이어야
한다.
프로세스는 독립적이어야 하고 기능 점수를 계산하는
어플리케이션의 비즈니스를 일관된 상태로 두어야 한다.
기능 점수 분석 (Function Point Analysis)
119
IFPUG의 EQ 계산 규칙 (계속)

식별된 프로세스에 대해 다음 규칙 중 하나가 적용되어야 한다.
1.
2.
3.
프로세싱 논리는 유일하거나 어플리케이션 내에서 다른 외부
조회에 의해 수행되는 프로세싱 논리와 상이해야 한다.
데이터 요소의 집합은 어플리케이션의 다른 외부 조회에 관해
식별된 집합과 상이하다.
참조되는 ILF나 EIF는 어플리케이션의 다른 외부 조회에 의해
참조되는 것들과 상이하다.
기능 점수 분석 (Function Point Analysis)
120
EQ의 예


하나 이상의 ILF, EIF로부터 검색되고 디스플레이되는 트랜잭션 데이터
View, lookup, display, browse, print와 같은 사용자 기능
»





독립적인(stand-alone) 프로세스로 사용될 수 있고 이전에 계산된 EQ의 중복이
아닌 (변경이나 삭제 기능 이전의 데이터 검색에) 함축된 조회
식, 계산, 유도된 데이터를 포함하지 않으며 ILF를 유지하지 않고 주기적으로
생성되는 리포트
계산되지 않고 유지되는 시스템 데이터, 매개변수, 설정치(set up)의 리턴
어플리케이션에 특정된 보안을 제공하는 로그 온 화면
각 수준의 HELP
»




동일한 프로세싱 논리를 가진 print와 view는 하나의 EQ로 계산됨
ILF나 EIF의 필드나 스크린 검색
전자식 데이터 인터페이스나 톤(tone) 방식의 전화를 통해 유지되는 데이터 검색
식, 계산, 유도된 데이터를 포함하지 않고 ILF를 유지하지 않는 다른
어플리케이션으로 송신되는 파일
메일 박스의 메일 검색
ILF나 EIF에서 유지되는 데이터를 리턴하기 위한 화면상의 리스트 박스 혹은
데이터의 포인팅과 클릭킹
기능 점수 분석 (Function Point Analysis)
121
EQ로 잘못 식별되는 예

동일한 논리를 호출하는 여러 방법
» 여러 화면에서 동일한 기능이나 트랜잭션을 수행하는 두 개의 액션 키는
오직 한 번만 계산


프로세싱 논리가 동일한 다중 미디어
어플리케이션의 여러 영역이나 화면에서 접근할 수 있는 조회
» 한 번만 계산



네비게이션이나 선택을 위해 사용되지만, 유지되는 데이터를 검색하지
않는 메뉴 화면
사용자가 어플리케이션에 들어갈 수 있게 하지만, 보안 조치가 없는
로그 온 화면
유도되거나 계산된 데이터의 검색
» EO로 계산됨


상이한 프로세싱 논리를 가지지 않는 데이터 집합의 재정렬이나 재배열
데이터를 확인하도록 사용자에게 요청하는 메시지에 대한 응답
기능 점수 분석 (Function Point Analysis)
122
EQ로 잘못 식별되는 예 (계속)



오류, 확인 메시지
온 라인 시스템 문서
동일한 어플리케이션 내의 온 라인과 일괄 처리 사이에 전달된 데이터
» 어플리케이션 경계를 넘지 않음

동일한 어플리케이션 내에서 클라이언트와 서버 사이에 전달된 데이터
시스템 로그 오프
» 어플리케이션 경계를 넘지 않음

유지되는 데이터에서 검색되지 않은 데이터
» 예: hard-coded 데이터는 계산하지 않음
기능 점수 분석 (Function Point Analysis)
123
EQ의 복잡도

EQ의 개수와 각각의 기능 복잡도가 함께 미조정된 기능 점수의
계산에 영향을 미친다. 식별된 각각의 EQ는 관련된 데이터 요소
타입(DET)과 참조 파일 타입(FTR)의 수를 기준으로 기능
복잡도가 결정된다.
» 기능 복잡도(functional complexity)는 DET와 FTR의 개수에 따라
low, average, high 중 하나의 등급을 부여함 (복잡도 행렬)
» 데이터 요소 타입(DET)은 어플리케이션의 경계를 넘고 사용자가
인식 가능한, 유일하고, 반복되지 않는 필드나 속성
» 참조 파일 타입(FTR)은 간단하게 참조 파일이라고 부르며, EQ
트랜잭션에 의해 유지되거나 읽히는 ILF와 EQ 트랜잭션에 의해
읽히는 EIF의 총 개수
기능 점수 분석 (Function Point Analysis)
124
IFPUG의 DET 계산 규칙

어플리케이션의 경계를 들어가고, 무슨 데이터가 언제 어떻게 기본
프로세스에 의해 검색, 생성되는가를 명세하는데 필요하고 사용자가
유일하게 식별 가능한 반복되지 않는 필드 각각에 대해 하나의 DET로
계산한다.
» 종종 제어 정보, 선택 정보, 프로세싱 매개변수로 고려

어플리케이션의 경계를 나가고, 사용자가 유일하게 식별 가능한
반복되지 않는 필드 각각에 대해 하나의 DET로 계산한다.
» 외래 키 속성과 제어 정보가 포함됨

만일 하나의 DET가 경계를 모두 들어오고 나가면, 기본 프로세스에
대해 단지 하나로만 계산
기능 점수 분석 (Function Point Analysis)
125
IFPUG의 DET 계산 규칙 (계속)

처리 동안 에러가 발생했음을 나타내거나, 처리가 완료되었음을
확인하거나, 처리가 계속되어야 함을 증명하기 위해 어플리케이션의
경계 밖으로 시스템 응답 메시지를 전송하는 기능에 대해 하나의 DET로
계산한다.
» 여러 메시지가 존재함에도 불구하고 메시지 전체를 하나의 DET로 계산

동일한 논리 프로세스를 호출하는 여러 방법이나 다중 키가
존재하더라도 EQ의 액션을 명세하는 기능에 대해 하나의 DET로
계산한다.
» OK 버튼, 기능 키, 액션 키, 마우스 클릭

페이지 번호, 위치 정보(행과 열), 페이지 명령(이전, 다음), 날짜/시간
필드를 포함하는 페이지 변수나 시스템이 생성하는 스탬프는 계산하지
않는다.
» DET는 검색된 날짜를 포함하나 리포트 인쇄 날짜와 같은 시스템 생성
날짜는 포함하지 않음
기능 점수 분석 (Function Point Analysis)
126
IFPUG의 DET 계산 규칙 (계속)

리포트 제목, 스크린 ID, 열 표제(column heading), 필드 제목을
포함하는 리터럴은 계산하지 않는다.

물리적으로는 다중 필드로 저장되었지만 사용자에 의해 단일 정보로
요구되는 논리적 필드에 대해서는 하나의 DET로 계산한다.
» 세 개의 필드로 저장되나 하나의 정보로 사용되는 날짜나 이름은 각각
하나의DET로 계산됨

그래픽 디스플레이에서 각 유형의 레이블과 동등한 각 수치에 대해 각각
하나의 DET로 계산한다.
» 저장된 데이터로 퍼센트 값을 읽는 것처럼 계산 없이 그래프가 생성되면,
그래프는 EQ가 될 수 있음

단일 단어, 문장, 단락, 여러 단락으로 구성될 수 있는 텍스트 정보에
관해 하나의 DET로 계산한다.
기능 점수 분석 (Function Point Analysis)
127
IFPUG의 FTR 계산 규칙

EQ의 처리 동안 읽히는 내부 논리 파일(ILF)이나 외부
인터페이스 파일(EIF) 각각에 대해서 하나의 FTR로 계산한다.
기능 점수 분석 (Function Point Analysis)
128
EQ의 계산 예: 요구사항

직원 정보를 유지, 조회, 기록하는 기능이 필요. 생성된 리포트는
다른 어플리케이션에 의해 유지되는 파일에서 얻은 직원에 대한
위치 데이터를 포함.

업무 정보를 유지, 조회, 기록하는 기능이 필요. 업무 기술(Job
Description)은 80 문자 단위의 라인들로 구성되고, 이 정보는
업무(Job)와 독립적으로 유지되지 않음

직원에 대한 업무 배정(Job Assignment)을 유지, 조회, 기록하는
기능이 필요.

회사 내의 특정 위치에 있는 직원의 리스트를 포함한 위치
데이터(Location Data)에서 위치를 조회하고 기록하는 기능이
필요. 이 위치 데이터는 읽을 수만 있고 다른 어플리케이션에
의해서 유지됨.
기능 점수 분석 (Function Point Analysis)
129
EQ의 계산 예: 프로세스 모델
EMPLOYEE-MAINTENANCE
CREATE-EMPLOYEE
EMPLOYEE-INQUIRY
UPDATE-EMPLOYEE
DELETE-EMPLOYEE
EMPLOYEE-REPORT
JOB-MAINTENANCE
CREATE-JOB
JOB-INQUIRY
UPDATE-JOB
DELETE-JOB
JOB-REPORT
기능 점수 분석 (Function Point Analysis)
130
프로세스 모델 (계속)
JOB-ASSIGNMENT-MAINTENANCE
ASSIGN-EMPLOYEE-TO-JOB
JOB-ASSIGNMENT-INQUIRY
TRANSFER-EMPLOYEE
EVALUATE-EMPLOYEE
DELETE-ASSIGNMENT
JOB-ASSIGNMENT-REPORT
LOCATION-REPORTING
LOCATION-INQUIRY
LOCATION-REPORT
기능 점수 분석 (Function Point Analysis)
131
ILF와 EIF의 계산 결과
EMPLOYEE 엔터티 타입: ILF, 서브 그룹이 존재하므로 별도의 RET 계산 않음
Employee_Name: DET 1
Social_Security_Number : DET 2
Nbr_Dependents: DET 3
Type_Code (Salaried 혹은 Hourly) : DET 4
Location_Name (외래 키): DET5
SALARIED_EMPLOYEE 엔터티 타입: EMPLOYEE 내의 RET 1
Supervisory_Level: DET 6
HOURLY_EMPLOYEE 엔터티 타입: EMPLOYEE 내의 RET 2
Standard_Hourly_Rate : DET 7
Collective_Bargaining_Unit_Number: DET 8
JOB 엔터티 타입: ILF, RET 1
Job_Name: DET 1
Job_Number : DET 2
Pay_Grade: DET 3
기능 점수 분석 (Function Point Analysis)
132
ILF와 EIF의 계산 결과
JOB_DESCRIPTION 엔터티 타입: 구현상의 이유로만 존재하는 JOB의 일부
Job_Number (외래 키): 이전에 DET 2로 계산됨
Line_Number : 구현상의 이유로만 존재
Description_Line: DET 4
JOB_ASSIGNMENT 엔터티 타입: ILF, RET 1, 자신의 속성을 가지고 별도로 유지됨
Effective_Date : DET 1
Salary : DET 2
Performance_Rating : DET 3
Job_Number (외래 키) : DET 4
Employee_SSN (외래 키) : DET 5
LOCATION 엔터티 타입 : EIF, RET 1
Location_Name : DET 1
Address : DET 2
Interoffice_Code : DET 3
기능 점수 분석 (Function Point Analysis)
133
ILF와 EIF의 복잡도 계산 결과

ILF와 EIF에 관한 복잡도 행렬에 의해 3개의 low ILF, 한 개의 low EIF
기능 점수 분석 (Function Point Analysis)
134
EQ의 계산 예: 복잡도 행렬
기능 점수 분석 (Function Point Analysis)
135
EQ의 계산 예: DET, FTR에 관한 가정

EO와 마찬가지로 EQ도 데이터 검색을 위해 어플리케이션의
경계를 들어가는 필드와 제어 정보를 가질 수 있음

각 제어 정보가 디스플레이됨을 가정

오류, 증명, 확인 메시지에 대해 하나의 DET로 계산

최소한 하나의 명령 키(command key)를 가짐

참조 파일은 하나만 존재
» 검증을 위해 다른 파일을 참조할 필요가 없고, 기본 파일을 제외한
파일에서 검색되는 필드가 없음
기능 점수 분석 (Function Point Analysis)
136
EQ의 계산 예: DET와 FTR
EMPLOYEE-INQUIRY: FTR 1, DET 10
(메시지와 명령 키를 각각 하나의 DET로 계산)
JOB-INQUIRY: FTR 1, DET 6
(메시지와 명령 키를 각각 하나의 DET로 계산)
JOB-ASSIGNMENT-INQUIRY: FTR 1, DET 7
(메시지와 명령 키를 각각 하나의 DET로 계산)
LOCATOIN-INQUIRY: FTR 1, DET 5
(메시지와 명령 키를 각각 하나의 DET로 계산)
기능 점수 분석 (Function Point Analysis)
137
EQ의 계산 예: 복잡도 행렬

4개의 low EQ
기능 점수 분석 (Function Point Analysis)
138
EQ의 계산 예: 미조정된 기능 점수

4개의 low EQ

미조정된 기능 점수는 12
기능 점수 분석 (Function Point Analysis)
139
4
일반 시스템 특성




개요
기능 점수 계산 과정
일반 시스템 특성
값 조정 인자
기능 점수 분석 (Function Point Analysis)
140
개요

정보 시스템이 제공하는 기능에는 데이터 기능과 트랜잭션
기능에 의해 충분히 표현되지 않는 일반적인 요인들이 있고,
FPA에 이를 반영하는 일반 시스템 특성(General System
Characteristics: GSC)이 있음

값 조정 인자(Value Adjustment Factor: VAF)는 조정된 기능
점수(adjusted function point) 계산을 위한 승수(multiplier)로
사용됨

일반 시스템 특성(GSC)을 모두 무시하고 미조정된 기능 점수로
최종적인 기능 점수를 대치하려는 일부 경향이 있음

ISO는 기능 점수 측정을 위해 일반 시스템 특성(GSC)을
배제하려는 작업을 진행 중임
기능 점수 분석 (Function Point Analysis)
141
개요: 일반 시스템 특성(GSC)
1. Data Communications
2. Distributed data processing
3. Performance
4. Heavily used configuration
5. Transaction rate
6. Online data entry
7. End user efficiency
8. Online update
9. Complex processing
10. Reusability
11. Installation ease
12. Operational ease
13. Multiple sites
14. Facilitate change
기능 점수 분석 (Function Point Analysis)
142
개요: 일반 시스템 특성 (계속)

14개의 일반 시스템 특성 (GSC)은 각각 독립적으로 계산되고,
영향의 정도 (Degree of Influence: DI)에 따라 0 (영향이 전혀
없음)부터 5 (강한 영향) 사이의 한 값이 할당됨

14개의 일반 시스템 특성 (GSC)은 전체적인 영향의 정도(Total
Degree of Influence: TDI)를 계산하기 위해 합산됨

조정된 기능 점수(adjusted function point)는 값 조정 인자 (Value
Adjustment Factor: VAF)를 이용하여 계산됨
» VAF = (TDI  0.01) + 0.65
» FP = UFP  VAF
기능 점수 분석 (Function Point Analysis)
143
기능 점수 계산 과정
1. 기능 점수의 유형 결정
2. 기능 점수 계산 범위와 어플리케이션 경계를 식별
3. 데이터 기능(내부 논리 파일, 외부 인터페이스 파일)과
복잡도 계산
4. 트랜잭션 기능(외부 입력, 외부 출력, 외부 조회)과
복잡도 계산
5. 미조정된 기능 점수(unadjusted function point) 계산
6. 일반 시스템 특성에 근거한 값 조정 인자 계산
7. 조정된 기능 점수(adjusted function point) 계산
기능 점수 분석 (Function Point Analysis)
144
일반 시스템 특성 (GSC)

0
1
2
3
4
5
각 GSC의 영향의 정도(DI)가 IFPUG의 지침에 따라 평가되어 0
에서 5 사이의 값을 가져야 한다.
존재하지 않거나 영향이 없음(Not present, or no influence)
우연한 영향(Incidental influence)
온건한 영향(Moderate influence)
평균적인 영향(Average influence)
중대한 영향(Significant influence)
시종 강한 영향(Strong influence throughout)
기능 점수 분석 (Function Point Analysis)
145
GSC: 1. Data communications

어플리케이션이 프로세서와 직접적으로 통신하는 정도를
나타낸다.
0 순수한 일괄 처리 혹은 stand-alone PC
1 일괄 처리이지만 원격 데이터 입력 혹은 원격 출력
2 일괄 처리이지만 원격 데이터 입력과 원격 출력
3 온 라인 데이터 수집 또는 일괄 처리나 질의 시스템에 대한 원격
처리(TP) front end를 포함
4 front end 이상의 것이지만, 오직 한 가지 유형의 TP 통신
프로토콜을 지원
5 front end 이상의 것이고, 어플리케이션이 한 가지 유형 이상의 TP
통신 프로토콜을 지원
기능 점수 분석 (Function Point Analysis)
146
GSC: 1. Data communications (계속)
David’s notes

순수한 일괄 처리 어플리케이션만이 0. 일괄 처리와 stand-alone
PC를 포함한 대부분의 어플리케이션은 원격 데이터 입력 기능
뿐만 아니라 원격 프린팅 기능을 가진다. front-end 데이터 입력
기능을 가졌지만, 일괄 처리를 통해 내부의 논리 파일을 갱신하는
어플리케이션은 3. 만일 갱신이 대화식으로 일어나면 4. 여러
유형의 원격 통신 프로토콜이 존재하면 5. 전형적인 일괄 처리
어플리케이션은 0에서 3, 온 라인 어플리케이션은 3에서 4,
실시간, 원격 통신, 혹은 프로세스 제어 시스템은 4 혹은 5.
기능 점수 분석 (Function Point Analysis)
147
GSC: 2. Distributed data processing

어플리케이션의 컴포넌트 사이에 데이터를 전송(transfer)하는 정도를
나타낸다. 분산 데이터 처리 기능은 어플리케이션 경계 내의 특성이다.
0 시스템의 컴포넌트 사이에 데이터나 프로세싱 기능의 전송을 돕지 않음
1 PC 스프레드 시트나 PC DBMS와 같은 다른 시스템의 컴포넌트 상에서
사용자 프로세싱을 위한 데이터를 준비
2 데이터는 전송을 위해 준비되고 나서, 시스템의 다른 컴포넌트(사용자
프로세싱을 위한 것이 아닌) 상으로 전송되고 처리됨
3 분산 처리와 데이터 전송이 온 라인이고 단지 한 방향으로만 이루어짐
4 분산 처리와 데이터 전송은 온 라인이고 양방향 모두로 이루어짐
5 프로세싱 기능은 시스템의 가장 적절한 컴포넌트에서 동적으로 수행됨
기능 점수 분석 (Function Point Analysis)
148
GSC: 2. Distributed data processing (계속)
David’s notes

분산 어플리케이션이나 실시간 어플리케이션은 이 범주내의
값이 지정되어야 한다. 대부분의 어플리케이션은 0,
기본적인(primitive) 분산 어플리케이션은 1이나 2, 클라이언트나
웹 어플리케이션은 2에서 4, 실시간, 원격 통신, 혹은 프로세스
제어 시스템은 0에서 5. 5의 값을 갖기 위해서는 다중 서버나
프로세서가 존재해야 하고, 각각은 실시간 가용성을 기초로
동적으로 선택된다.
기능 점수 분석 (Function Point Analysis)
149
GSC: 3. Performance

어플리케이션 개발에 영향을 주는 응답 시간(response time)과
처리율(throughput)의 performance를 고려하는 정도를 나타낸다.
0 사용자에 의한 특별한 성능 요구가 없음
1 성능과 설계 요구가 언급되고 검토되지만, 특별한 액션이 요구되지 않음
2 응답 시간이나 처리율이 peak hours동안 중요함. CPU 활용에 대한
특별한 설계가 요구되지 않음. 프로세싱 데드라인은 그 다음 날
3 응답 시간이나 처리율이 모든 시간 동안 중요함. CPU 활용에 대한 특별한
설계가 요구되지 않음. 인터페이싱 시스템을 가진 프로세싱 데드라인
요구사항이 강하게 제기됨
4 추가적으로, 언급된 사용자 성능 요구사항은 설계 단계에서 성능 분석
작업이 필요할 정도로 매우 엄격함
5 추가적으로, 언급된 사용자 성능 요구를 만족하기 위해 설계, 개발, 구현
단계에서 성능 분석 도구가 사용됨
기능 점수 분석 (Function Point Analysis)
150
GSC: 3. Performance (계속)
David’s notes

transaction rate(GSC 5)와 그 성격이 매우 유사하다. 둘 모두가
설계, 개발, 설치 단계에서 성능을 고려한다. 응답 시간은
전형적으로 대화식 프로세싱과 관련되고, 처리율은 일괄 처리와
관련된다. 설계 단계 동안 성능 분석 작업을 요구하면 4, 성능
분석 도구의 이용을 요구하면 5. 전형적으로 일괄 처리
어플리케이션은 0에서 4, 온 라인 어플리케이션은 0에서 4.
그리고 실시간, 원격 통신, 프로세스 제어 시스템은 0에서 5.
기능 점수 분석 (Function Point Analysis)
151
GSC: 4. Heavily used configuration

어플리케이션의 개발에 영향을 주는 컴퓨터 자원의 제한 정도를
나타낸다.
0 명시적이거나 암시적인 운영상의 제한이 포함되지 않음
1 운영상의 제한이 존재하지만, 전형적인 어플리케이션보다 덜
제한적임. 제한을 만족하기 위한 특별한 노력이 필요하지 않음
2 어떤 보안 고려 사항이나 타이밍 고려 사항이 포함됨
3 어플리케이션의 특정 부분에 대해 특정 프로세서 요구사항이
포함됨
4 언급된 운영상의 제한이 중앙 처리기나 전용 처리기에 특별한
제한을 요구함
5 추가적으로, 시스템의 분산 컴포넌트에 특별한 제한이 존재함
기능 점수 분석 (Function Point Analysis)
152
GSC: 4. Heavily used configuration (계속)
David’s notes

대부분의 어플리케이션이 2의 값을 가짐. 어플리케이션이
클라이언트-서버, 실시간, 원격 통신, 프로세스 제어 시스템이면
3에서 5. 동일한 트랜잭션을 처리하고 가장 신속한 처리 수단을
탐색하는 전용 처리기나 다중 처리기가 필요할 수 있다.
기능 점수 분석 (Function Point Analysis)
153
GSC: 5. Transaction rate

어플리케이션의 개발에 영향을 주는 비즈니스 트랜잭션의 비율을
나타낸다. Transaction rate가 높은 것은 어플리케이션의 설계, 개발,
설치, 지원에 영향을 준다.
0 peak transaction period가 예상되지 않음
1 월별, 분기별, 계절별, 년별 peak transaction period가 예상됨
2 주별 peak transaction period가 예상됨
3 일일 peak transaction period가 예상됨
4 어플리케이션 요구 사항이나 서비스 수준에서 사용자에 의해 언급된 High
transaction rate는 설계 단계에서 성능 분석을 요구하기에 충분할
정도로 높음
5 어플리케이션 요구 사항이나 서비스 수준에서 사용자에 의해 언급된 High
transaction rate는 설계 단계에서 성능 분석을 요구하기에 충분할
정도로 높고, 추가적으로 설계, 개발, 설치 단계에서 성능 분석 도구의
이용을 요구함
기능 점수 분석 (Function Point Analysis)
154
GSC: 5. Transaction rate (계속)
David’s notes

Performance(GSC 3)와 그 성격이 매우 비슷하다. 둘 모두가
설계, 개발, 설치 단계에서 성능을 고려한다. 설계 단계 동안 성능
분석 작업을 요구하면 4, 성능 분석 도구의 이용을 요구하면 5.
전형적으로 일괄 처리 어플리케이션은 0에서 3. 온 라인
어플리케이션은 0에서 4. 실시간, 원격 통신, 프로세스 제어
시스템은 0에서 5.
기능 점수 분석 (Function Point Analysis)
155
GSC: 6. Online data entry

0
1
2
3
4
5
데이터가 대화식(interactive) 트랜잭션을 통해 입력되는 정도를
나타낸다.
모든 트랜잭션이 일괄 처리 모드에서 처리
트랜잭션의 1에서 7 퍼센트가 대화식 데이터 입력
트랜잭션의 8에서 15 퍼센트가 대화식 데이터 입력
트랜잭션의 16에서 23 퍼센트가 대화식 데이터 입력
트랜잭션의 24에서 30 퍼센트가 대화식 데이터 입력
트랜잭션의 30 퍼센트 이상이 대화식 데이터 입력
기능 점수 분석 (Function Point Analysis)
156
GSC: 6. Online data entry (계속)
David’s notes

EI, EO, EQ 트랜잭션 각각은 기본 프로세스이다. GSC에 관한
큰 문제 중의 하나는 IFPUG의 지침이 수년간 갱신되지 않았다는
것이다. 그 결과로 인해 이 값들은 실제적이지 않다. 그럼에도
불구하고 industry data는 이 지침들을 이용해 계산되어 왔다.
전형적으로 일괄 처리 어플리케이션은 0에서 1, 그리고 온 라인,
실시간, 원격 통신, 프로세스 제어 시스템이 5의 값을 가진다.
기능 점수 분석 (Function Point Analysis)
157
GSC: 7. End user efficiency

Human factors와 사용의 용이성을 나타낸다.
Navigational aids(예: 기능 키, 점프, 동적으로 생성된 메뉴)
메뉴
온 라인 HELP와 문서
자동화된 커서 이동
스크롤링
원격 프린팅(온 라인 트랜잭션을 경유)
미리지정된 기능 키
온 라인 트랜잭션으로부터 제출된 일괄 처리 작업
스크린 데이터의 커서 선택
역상 비디오, 강조, 색, 밑줄, 다른 표시 기호의 사용
온 라인 트랜잭션의 하드 카피 사용자 문서화
마우스 인터페이스
팝업 윈도우
비즈니스 기능을 달성하기 위해 가능한 한 적은 스크린
이중 언어 지원(네 개의 항목으로 계산됨)
다중 언어 지원(여섯 개의 항목으로 계산됨)
기능 점수 분석 (Function Point Analysis)
158
GSC: 7. End user efficiency (계속)

앞에서 기술된 항목의 포함 여부를 기준으로
어느 것도 포함되지 않음
하나부터 세 개까지 포함
네 개부터 다섯 개까지 포함
여섯 개 이상 포함되나, 효율성에 관련된 특정한 사용자 요구사항이
존재하지 않음
4 여섯 개 이상 포함되고, 최종 사용자 효율성에 관해 언급된 요구사항은
human factors를 위한 설계 작업을 포함되도록 요구함 (예를 들어, key
stroke의 최소화, 디폴트의 최대화, 템플릿의 이용)
5 여섯 개 이상 포함되고, 최종 사용자 효율성에 관해 언급된 요구사항은
목적이 달성되었다는 것을 예시하기 위한 특별한 도구와 프로세스의
이용을 요구함
0
1
2
3
기능 점수 분석 (Function Point Analysis)
159
GSC: 7. End user efficiency (계속)
David’s notes

순수한 일괄 처리 어플리케이션은 0. front-end 데이터 입력
화면을 가지지만, 내장된 템플릿이나 디폴트를 가지지 않는
대부분의 어플리케이션은 3. 만일 디폴트, 템플릿, 중요한
네비게이션 도구가 존재하면 4. 기능성보다는 어플리케이션의
유용성을 시험할 사용자 실험실이 존재하면 5. 실시간, 원격
통신, 프로세스 제어 시스템은 이 GSC에 해당되지 않음.
기능 점수 분석 (Function Point Analysis)
160
GSC: 8. Online update

내부 논리 파일이 온 라인으로 갱신되는 정도를 나타낸다.
0 온 라인 갱신이 없음
1 하나에서 세 개의 제어 파일의 온 라인 갱신이 포함됨. 갱신되는
양이 적고 복구가 쉬움
2 네 개 이상의 제어 파일의 온 라인 갱신이 포함됨. 갱신되는 양이
적고 복구가 쉬움
3 주요 내부 논리 파일의 온 라인 갱신이 포함됨
4 추가적으로, 데이터 손실을 막기 위한 보호가 필수적이고
시스템에서 특별하게 설계되고 프로그램됨
5 추가적으로, 많은 양의 갱신이 복구 과정에서 비용을 고려하게 함.
운영자의 간섭을 최소화한 고도로 자동화된 복구 절차가 포함됨
기능 점수 분석 (Function Point Analysis)
161
GSC: 8. Online update (계속)
David’s notes

내부 논리 파일을 대화식으로 갱신하는 일괄 처리
어플리케이션은 0에서 2. 내부 논리 파일을 갱신하는 대부분의
온 라인 어플리케이션은 3 이상. 만일 시스템 안에 데이터의
손실을 보호하는 기능이 프로그램되면(단지 백업을 통한 것이
아니라) 4. 어플리케이션 내에 내장된 고도로 자동화된 복구
기능이 존재하면 5. 실시간, 원격 통신, 프로세스 제어 시스템은
대개 4 혹은 5.
기능 점수 분석 (Function Point Analysis)
162
GSC: 9. Complex processing

프로세싱 논리가 어플리케이션의 개발에 영향을 미친 정도를
나타낸다.

컴포넌트의 종류
1. 민감한 제어(sensitive control), 특정한 보안 처리
2. 광범위한(extensive) 논리적인 처리
3. 광범위한(extensive) 수학적인 처리
4. 다시 처리되어야 하는 불완전한 트랜잭션으로 귀결되는 많은
예외 처리(예: TP 인터럽션에 기인한 불완전한 ATM 트랜잭션,
데이터 값의 손실, 실패한 검증)
5. 다중 입출력 가능성을 다루기 위한 복잡한 처리 (예: 멀티미디어,
기기 독립적인 입출력)
기능 점수 분석 (Function Point Analysis)
163
GSC: 9. Complex processing (계속)

0
1
2
3
4
5
앞에서 기술된 컴포넌트의 포함 여부를 기준으로
아무 것도 포함되지 않음
하나가 포함됨
두 가지가 포함됨
세 가지가 포함됨
네 가지가 포함됨
다섯 가지 모두가 포함됨
기능 점수 분석 (Function Point Analysis)
164
GSC: 9. Complex processing (계속)
David’s notes
이 GSC 지침은 다섯 가지의 별도의 개별적인 특성을 가진다.
1. 어플리케이션이 특정 개인에게 다른 사람은 할 수 없는 데이터를
보거나 입력하도록 보안을 제공하는가?
2. 논리적인 (if/then/else) 프로세싱이 광범위하게 존재하는가?
3. 수학적인 프로세싱이 광범위하게 (덧셈과 뺄셈과 같은 단순한
수학 이상의) 존재하는가?
4. 복잡한 편집이나 검증(validations)이 존재하는가?
5. 어플리케이션에 다중 미디어(예, 음성 입력과 스크린 입력)가
포함되는가?
기능 점수 분석 (Function Point Analysis)
165
GSC: 10. Reusability

다른 어플리케이션에서 이용 가능하도록 어플리케이션과 어플리케이션
내의 코드가 특별하게 설계, 개발, 지원되는 정도를 나타낸다.
0 재사용 가능한 코드가 없음
1 재사용 가능한 코드가 어플리케이션 내에서 사용됨
2 어플리케이션의 10 퍼센트 미만이 한 명 이상의 사용자 요구(needs)를
고려함
3 어플리케이션의 10 퍼센트 이상이 한 명 이상의 사용자 요구(needs)를
고려함
4 어플리케이션이 재사용을 용이하게 하기 위해 특별히 패키지되거나
문서화됨, 그리고 어플리케이션이 소스 코드 수준에서 사용자에 의해
재사용을 위해 수정 가능
5 어플리케이션이 재사용을 용이하게 하기 위해 특별히 패키지되거나
문서화됨, 그리고 어플리케이션이 유지보수에 의해 수정 가능
기능 점수 분석 (Function Point Analysis)
166
GSC: 10. Reusability (계속)
David’s notes

재사용 코드를 사용하는 사람에게는 1의 값을 할당한다.
표준화된 재사용 가능한 소프트웨어는 신뢰도와 일관성이
향상되어 사용자를 위한 기능이 증가된다. 그 기능을 기초로
2에서 5 사이의 값이 할당되고, 다른 어플리케이션에서
활용되기를 기대하여 개발, 문서화, 코드의 시험에 추가 노력을
투입한다.
기능 점수 분석 (Function Point Analysis)
167
GSC: 11. Installation ease

어플리케이션의 개발에 이전의 환경의 컨버전이 영향을 주는 정도를
나타낸다.
0 사용자에 의해 언급된 특별한 고려사항이 없고, 설치를 위해 요구되는
특별한 설정(set up)이 없음
1 사용자에 의해 언급된 특별한 고려사항이 없지만, 설치를 위해 특별한
설정이 요구됨.
2 사용자에 의해 컨버전과 설치 요구 사항이 언급되고, 컨버전과 설치
지침이 제공되고 시험됨. 프로젝트에 대한 컨버전의 영향은 중요하게
고려되지 않음
3 사용자에 의해 컨버전과 설치 요구 사항이 언급되고, 컨버전과 설치
지침이 제공되고 시험됨. 프로젝트에 대한 컨버전의 영향은 중요하게
고려됨
4 위의 2에 추가하여, 자동화된 컨버전과 설치 도구가 제공되고 시험됨
5 위의 3에 추가하여, 자동화된 컨버전과 설치 도구가 제공되고 시험됨
기능 점수 분석 (Function Point Analysis)
168
GSC: 11. Installation ease (계속)
David’s notes

종종 개발자들은 이전에 존재했던 데이터를 새로운 데이터
파일로 변환하고, 파일이 실제의 데이터를 가지게 하고, 이식을
위한 설치 소프트웨어를 개발하기 위한 많은 노력을 투입할 것을
요구 받는다. 일정이 개선되고 일관성이 증가되면 사용자에게
제공되는 기능이 향상된다. 컨버전과 설치 요구 사항의 어려움과
쉬움, 중요성에 따라 점수를 부여한다.
기능 점수 분석 (Function Point Analysis)
169
GSC: 12. Operational ease

시동, 백업, 복구 절차와 같은 운영 측면에 주의하는 정도를 나타낸다.
0 정상적인 백업 절차를 제외하고 사용자에 의해 언급된 특별한 운영상의
고려 사항이 없음
1-4 어플리케이션에 적용할 다음의 항목을 선택한다. 각 항목은 특별하게
언급된 것을 제외하고는 1의 값을 가진다.
효과적인 시동, 백업, 복구 절차가 제공되지만, 운영자의 간섭이 요구됨
효과적인 시동, 백업, 복구 절차가 제공되지만, 운영자의 간섭이 요구되지
않음(두 항목으로 계산됨)
테이프 마운트의 필요가 최소화됨
페이퍼 핸들링 필요가 최소화됨
5 어플리케이션이 무인 운영을 위해 설계됨. 무인 운영은 어플리케이션의
시동과 셧 다운을 제외하고 시스템을 운영하기 위해 운영자 간섭이
요구되지 않음 을 의미한다. 자동적인 오류 복구가 어플리케이션의
특성이다.
기능 점수 분석 (Function Point Analysis)
170
GSC: 12. Operational ease (계속)
David’s notes

레거시 시스템이 아닌 한, 테이프 마운트와 페이퍼(천공 카드,
천공 페이퍼 테이프)가 없으면 각각 1의 값을 부여한다. 만일
시동, 백업, 복구를 위해 운영자 간섭이 요구되면 3의 값을
부여한다. 만일 운영자 간섭이 요구되지 않으면 4의 값을
부여하고, 어플리케이션이 스스로 운영되고 오류로부터
자동적으로 복구되면 5의 값을 부여한다. 대개 온 라인
어플리케이션에 대해서는 3의 값을 부여하고, 운영자에 의해
직접 방해 받지 않고 운영되는 플랜트-프로세싱, 원격 통신,
실시간 시스템을 위해 더 높은 값을 부여한다.
기능 점수 분석 (Function Point Analysis)
171
GSC: 13. Multiple sites

여러 장소의 사용자 조직을 위해 개발되는 정도를 나타낸다 .
0 한 명 이상의 사용자나 사이트의 필요(needs)를 고려하도록 요구되지
않음
1 여러 사이트의 필요성이 설계에서 고려되었고, 어플리케이션은 오직
동일한 하드웨어와 소프트웨어 환경 아래에서만 운영되도록 설계됨
2 여러 사이트의 필요성이 설계에서 고려되었고, 어플리케이션은 오직
유사한 하드웨어와 소프트웨어 환경 아래에서만 운영되도록 설계됨
3 여러 사이트의 필요성이 설계에서 고려되었고, 어플리케이션은 오직
상이한 하드웨어와 소프트웨어 환경 아래에서만 운영되도록 설계됨
4 여러 사이트에서 어플리케이션을 지원하도록 문서화 계획과 지원 계획이
제공되고 시험됨, 그리고 어플리케이션은 위의 1이나 2로 기술됨
5 여러 사이트에서 어플리케이션을 지원하도록 문서화 계획과 지원 계획이
제공되고 시험됨, 그리고 어플리케이션은 위의 3으로 기술됨
기능 점수 분석 (Function Point Analysis)
172
GSC: 13. Multiple sites (계속)
David’s notes

여러 사이트에서 운영될 소프트웨어, 하드웨어를 포함하는
어플리케이션을 인도하는데 필요한 노력과 사용자 기능을
고려한다. 터미널이나 PC와 같은 입력 장치를 반영한다.
소프트웨어, 하드웨어가 동일, 유사(윈도우 95, NT),
상이한가(윈도우, Mac, Unix)? 문서가 제공되고 시험 계획을
지원하는가?
기능 점수 분석 (Function Point Analysis)
173
GSC: 14. Facilitate change

변경을 쉽도록 하기 위해 어플리케이션이 특별하게 설계, 개발,
지원되는 정도를 나타낸다.
0 변경을 최소화하거나 촉진하도록 어플리케이션을 설계하는 특별한 사용자 요구
사항이 없음
1-5 어플리케이션에 적용할 다음의 항목을 선택한다.
융통성 있는 질의와 리포트 기능이 제공되고 simple 복잡도의 조회를 다룰 수
있음 - 예를 들어, 오직 하나의 내부 논리 파일에 적용되는 and/or 논리(한
항목으로 계산됨)
융통성 있는 질의와 리포트 기능이 제공되고 average 복잡도의 조회를 다룰 수
있음 - 예를 들어, 하나 이상의 내부 논리 파일에 적용되는 and/or 논리(두
항목으로 계산됨)
융통성 있는 질의와 리포트 기능이 제공되고 complex 복잡도의 조회를 다룰 수
있음 - 예를 들어, 하나 이상의 내부 논리 파일에 적용되는 and/or 논리의
조합 (세 항목으로 계산됨)
비즈니스 제어 데이터가 온 라인 대화식 프로세스를 가진 사용자에 의해
유지되는 테이블에 보관되지만, 변경은 단지 그 다음 날에만 효과가 있음(한
항목으로 계산됨)
비즈니스 제어 데이터가 온 라인 대화식 프로세스를 가진 사용자에 의해
유지되는 테이블에 보관되지만, 변경은 즉시 효과가 있음(두 항목으로
계산됨)
기능 점수 분석 (Function Point Analysis)
174
GSC: 14. Facilitate change (계속)
David’s notes




융통성 있는 질의와 리포트 기능이 제공된다.
제어 데이터는 사용자에 의해 유지 가능한 테이블에서 그룹화된다.
첫 번째 영역은 SQL이나 FOCUS와 같은 언어 혹은 더욱 동적인 리포트
생성 도구(예, Crystal Reports)에 의해 제공되는 질의, 리포트 작성
기능을 다룬다. 이러한 특성에는 0에서 3의 값을 할당한다.
두 번째 영역과 마지막 두 항목은 데이터, 제어 정보가 어플리케이션
내에서 혹은 어플리케이션에 의해 유지되는 상호작용(interactivity)에
관련된다. 대화형, 실시간, 원격 통신, 프로세스 제어 시스템은
전형적으로 마지막 두 값을 할당한다.
기능 점수 분석 (Function Point Analysis)
175
값 조정 인자 (VAF)

14개의 일반 시스템 특성(GSC)이 값 조정 인자(VAF)로
합산된다. VAF는 조정된 기능 점수 계산을 결정하기 위해
미조정된 기능 점수 계산을 ±35 퍼센트 범위에서 조정한다.

일반적으로, 간단한 일괄 처리 어플리케이션은 15 미만, frontend 일괄 처리 어플리케이션은 15에서 30 사이, 실시간, 원격
통신, 프로세스 제어 시스템은 30에서 60 사이의 TDI를 가진다.

다음 절차에 의해 VAF를 계산한다.
1. 각 GSC에 관한 영향의 정도(DI)를 결정하기 위해 0에서 5사이의
값으로 14개의 GSC를 평가한다.
2. 전체 영향의 정도(TDI)를 구하기 위해 14개의 GSC의 DI를 더한다.
3. 다음 식으로 VAF를 계산한다.
VAF = (TDI × 0.01) + 0.65
기능 점수 분석 (Function Point Analysis)
176
5
기능 점수의 계산과 응용




개요
조정된 기능 점수 계산
예: Catalog 비즈니스
기능 점수 계산 공식
기능 점수 분석 (Function Point Analysis)
177
개요

기능 점수를 계산하는 방법을 빠르고 쉽게 설명하기 위해
catalog 비즈니스의 예를 검토

데이터 기능과 트랜잭션 기능의 식별 규칙을 값 조정
인자(VAF)와 함께 사용하여 조정된 기능 점수(adjusted function
point)를 계산
» 데이터 기능과 트랜잭션 기능은 각각의 복잡도 행렬에 기초하여
미조정된 기능 점수 가중치를 가짐
» 일반 시스템 특성(GSC)은 각각 독립적으로 계산되어 0과 5 사이의
유일한 값이 할당되고, 이 값들이 더해져 TDI가 계산됨
» TDI를 이용하여 VAF를 계산하고, VAF는 미조정된 기능 점수에
곱해져 조정된 기능점수를 구함
기능 점수 분석 (Function Point Analysis)
178
조정된 기능 점수 계산
1. 기능 점수의 유형 결정
2. 기능 점수 계산 범위와 어플리케이션 경계를 식별
3. 데이터 기능(내부 논리 파일, 외부 인터페이스 파일)과
복잡도 계산
4. 트랜잭션 기능(외부 입력, 외부 출력, 외부 조회)과
복잡도 계산
5. 미조정된 기능 점수(unadjusted function point) 계산
6. 일반 시스템 특성에 근거한 값 조정 인자 계산
7. 조정된 기능 점수(adjusted function point) 계산
기능 점수 분석 (Function Point Analysis)
179
예: Catalog 비즈니스
Descriptions:
add, change,
delete
Business Catalog
Descriptions
Descriptions:
retrieve
Sales:
add, change, delete
Sales
Sales:
retrieve
Inventory
Vendor
Address
File
Inventory:
add, change,
delete
Inventory:
retrieve
End-of-Month Report
기능 점수 분석 (Function Point Analysis)
180
예: Catalog 비즈니스 – ILF의 복잡도

Descriptions 파일은 내부 논리 파일(ILF)
» 유일한 키(그리고 RET)는 item number이고 30개의 별도의 상이한
필드를 가지므로 low ILF
» 항목 정보를 추가(add)할 때 16개 이상의 필드(DET)와 한 개의
FTR(Descriptions 파일)이 존재하므로 average EI
» 항목 정보를 변경(change)할 때 16개 이상의 DET와 한 개의 FTR이
존재하므로 average EI
» 가용하지 않은 항목을 삭제(delete)할 때 5개 미만의
DET(어플리케이션의 경계를 지나는 필드)와 한 개의 FTR을
가지므로 low EI
» 항목 정보를 검색(retrieve)하여 한 개의 파일(FTR)에서 20개 이상의
DET를 디스플레이하는 트랜잭션은 average EQ
» low ILF가 한 개, average EI가 2개, low EI가 1개, average EQ가 1개
기능 점수 분석 (Function Point Analysis)
181
예: Catalog 비즈니스 – 복잡도(계속)

ILF인 Inventory 파일과 Sales 파일에 대해서도 동일한 가정을
하면
»
»
»
»

low ILF가 2개
average EI가 4개
low EI가 2개
average EQ가 2개
End-of-Month Report는 EO
» 20개 이상의 DET를 포함하고 두 개 이상의 FTR에서 데이터를
검색하면 high EO

외부 인터페이스 파일(EIF): Vendor Address File
» low EIF로 가정 (다른 어플리케이션에서 유지되고 EO에 관한 FTR)
기능 점수 분석 (Function Point Analysis)
182
예: Catalog 비즈니스 – 복잡도(계속)
기능 점수 분석 (Function Point Analysis)
183
예: Catalog 비즈니스 – 복잡도(계속)
기능 점수 분석 (Function Point Analysis)
184
예: Catalog 비즈니스 – 복잡도(계속)
기능 점수 분석 (Function Point Analysis)
185
예: Catalog 비즈니스 – 복잡도(계속)

3 개의 low EI의 점수는 각각 3이고, 전체는 9.
6 개의 average EI의 점수는 각각 4이고, 전체는 24.
1 개의 high EO의 점수는 7이고, 전체는 7.
3 개의 average EQ의 점수는 각각 4이고, 전체는 12.
3 개의 low ILF의 점수는 각각 7이고, 전체는 21.
1 개의 low EIF의 점수는 5이고, 전체는 5.

미조정된 기능 점수는 78.





기능 점수 분석 (Function Point Analysis)
186
예: Catalog 비즈니스 – GSC와 TDI
1. Data Communications - 4
2. Distributed data processing - 0
3. Performance - 3
4. Heavily used configuration - 2
5. Transaction rate - 3
6. Online data entry - 5
7. End user efficiency - 4
8. Online update - 3
9. Complex processing - 1
10. Reusability - 0
11. Installation ease - 0
12. Operational ease - 3
13. Multiple sites - 1
14. Facilitate change - 2

전체 영향의 정도(TDI) : 31
기능 점수 분석 (Function Point Analysis)
187
예: Catalog 비즈니스 – VAF와 FP

VAF = (TDI × 0.01) + 0.65 = 0.96

FP (Adjusted Function Point) = UFP × VAF = 75
기능 점수 분석 (Function Point Analysis)
188
예: Catalog 비즈니스 - worksheet
Function Point Calculation Worksheet
Project Number
Project Name
Type of Count: Development Project/Application Counting (circle one)
Phase of Count: Proposal/Requirements/Design/Code/Test/Delivery (circle one)
Date of Count
Counter’s Name
Function Levels
Components
External inputs
External outputs
External inquiries
Internal logical files
External interface files
Low
3×3
×4
×3
3×7
1×5
Average
6×4
×5
3×4
× 10
×7
High
×6
1×7
×6
× 15
× 10
Total
33
7
12
21
5
Total unadjusted Function Points (UFP) = 78
기능 점수 분석 (Function Point Analysis)
189
예: Catalog 비즈니스
– worksheet (계속)
General System Characteristics
Degree of
Characteristic
Influence
1. Data communications
4
2. Distributed data processing
0
3. Performance
3
4. Heavily used configuration
2
5. Transaction rate
3
6. Online data entry
5
7. End user efficiency
4
Characteristic
8. Online update
9. Complex processing
10. Reusability
11. Installation ease
12. Operational ease
13. Multiple sites
14. Facilitate change
Degree of
Influence
3
1
0
0
3
1
2
Total degree of influence (TDI) = 31
VAF
FP
Value adjustment factor
=
Adjusted function point count =
(TDI × 0.01) + 0.65 = 0.96
UFP × VAF
= 75
기능 점수 분석 (Function Point Analysis)
190
기능 점수 계산 공식: 개발 프로젝트

개발 프로젝트 기능 점수

개발 프로젝트 기능 점수 계산은 세 가지 기능의 컴포넌트로
구성된다.
1. EI, EO, EQ로 구성되는 어플리케이션의 미조정된 기능 점수 계산
2 . 이 전 데 이 터 를 새 로 운 ILF 로 변 환 하 는 컨 버 전 기 능 ( 이
컴포넌트는 종종 이전 데이터 파일의 입력으로 구성된다 [EI로
계산되거나 이미 계산된 새로운 ILF로의 입력 데이터] 그리고
컨버전 리포트에 관한 EO도 가능)
3. 어플리케이션 값 조정 인자 (VAF)
기능 점수 분석 (Function Point Analysis)
191
기능 점수 계산 공식:

개발 프로젝트 기능 점수

개발 프로젝트 기능 점수 계산 공식
개발 프로젝트 (계속)
DFP = (UFP + CFP) × VAF
DFP는 개발 프로젝트 기능 점수
UFP는 미조정된 기능 점수
CFP는 데이터의 컨버전에 의해 포함되는 기능 점수.
VAF는 값 조정 인자
기능 점수 분석 (Function Point Analysis)
192
기능 점수 계산 공식: 확장 프로젝트

확장 프로젝트 기능 점수
1. EI, EO, EQ, ILF, EIF로 구성되는 어플리케이션의 미조정된 기능 점수
•
확장 프로젝트에 의한 추가(이전에 존재하지 않았던 기능 – 예: 새로운
EQ, EI, ILF, EO)
•
확장 프로젝트에 의한 변경(이전에 존재했으나 현재 상이한 필드,
FTR을 가지는 기능, 상이한 프로세싱을 요구하는 기능)
•
확장 프로젝트에 의한 삭제(어플리케이션에서 삭제 – 예:삭제된 리포트)
2. 이전의 데이터를 새로운 ILF로 변환하는 컨버전 기능(종종 예전의 데이터
파일의 입력으로 구성된다[EI로 계산되거나 새로운 ILF의 입력 데이터]
그리고 컨버전 리포트에 관한 EO도 가능)
3. 두 개의 값 조정 인자(VAF는 변경될 수 있음, 이 경우에 이전의 VAF와
새로운 VAF가 존재할 수 있음)
기능 점수 분석 (Function Point Analysis)
193
기능 점수 계산 공식: 확장 프로젝트 (계속)

확장 프로젝트 기능 점수 계산 공식
EFP = [(ADD + CHGA + CFP) × VAFA] + (DEL × VAFB)
EFP는 확장 프로젝트 기능 점수
ADD는 확장 프로젝트에 의해 추가된 기능들의 미조정된 기능 점수
CHGA는 확장 프로젝트에 의해 수정된 기능들의 미조정된 기능 점수(이
컴포넌트는 단지 수정에 의해 추가된 필드가 아닌, 수정이 이루어진
후의 기능의 값을 반영한다. 전형적인 에러는 변경된 DET와 FTR, 혹은
RET만을 계산하는 것이다. 그러나 변경된 것뿐만 아니라 기존 기능의
시험에 포함된 노력을 고려해야 한다)
CFP는 데이터의 컨버전에 의해 포함된 기능 점수
VAFA는 확장 프로젝트 이후의 어플리케이션의 값 조정 인자
DEL은 확장 프로젝트에 의해 삭제된 기능의 미조정된 기능 점수
VAFB는 확장 프로젝트 이전의 어플리케이션의 값 조정 인자
기능 점수 분석 (Function Point Analysis)
194
기능 점수 계산 공식: 어플리케이션

어플리케이션 기능 점수

컨버전은 개발 프로젝트의 부분이므로 설치된 어플리케이션의
기능 점수 계산에 포함되지 않음

어플리케이션 기능 점수는 다음 컴포넌트로 구성됨
1. EI, EO, EQ, ILF, EIF로 구성되는 어플리케이션의 미조정된 기능
점수
2. 어플리케이션 값 조정 인자 (VAF)
기능 점수 분석 (Function Point Analysis)
195
기능 점수 계산 공식:

어플리케이션 (계속)
어플리케이션 기능 점수 계산 시점
1. 어플리케이션이 초기에 인도될 때
2. 확장 프로젝트가 어플리케이션의 기능을 변경할 때
• 어플리케이션의 기능 점수가 증가되는 (새로운) 기능의 추가
• 어플리케이션의 기능 점수가 증가, 감소되거나 혹은 영향이 없는
기능의 변경
• 어플리케이션의 기능 점수가 감소되는 기능의 삭제
• 어플리케이션의 기능 점수가 증가, 감소되거나 혹은 영향이 없는
값 조정 인자의 변경
기능 점수 분석 (Function Point Analysis)
196
기능 점수 계산 공식:
어플리케이션 (계속)

초기의 어플리케이션 기능 점수 계산

초기의 어플리케이션 기능 점수 계산 공식
AFP = ADD × VAF
AFP는 초기의 기능 점수
ADD는 개발 프로젝트에 의해 설치된 기능의 미조정된 기능 점수
VAF는 값 조정 인자
기능 점수 분석 (Function Point Analysis)
197
기능 점수 계산 공식:
어플리케이션 (계속)

확장 후의 어플리케이션 기능 점수 계산

확장 후의 어플리케이션 기능 점수 계산 공식
AFP = [(UFPB + ADD + CHGA) - (CHGB + DEL)] × VAFA
AFP는 어플리케이션의 조정된 기능 점수
UFPB는 확장 프로젝트 이전의 어플리케이션 미조정된 기능 점수
ADD는 확장 프로젝트에 의해 추가된 기능의 미조정된 기능 점수
CHGA는 확장 프로젝트에 의해 변경된 기능의 미조정된 기능 점수(변경
후의 기능 점수 값을 반영)
CHGB는 변경 이전에 확장에 의해 변경된 기능의 미조정된 기능 점수(확장
프로젝트 이전의 기능 점수 값을 반영)
DEL은 확장 프로젝트에 의해 삭제된 기능의 미조정된 기능 점수
VAFA는 확장 프로젝트 이후 어플리케이션의 값 조정 인자
기능 점수 분석 (Function Point Analysis)
198
6
사례 연구




개요
기초적인 사례 연구
프로젝트 관리 사례 연구
초기 정의 단계에서 기능 점수 계산
기능 점수 분석 (Function Point Analysis)
199
개요

기능 점수의 실제적인 계산 예

서로 연결되는 작은 두 개의 문제로 구성되는
기초적인 사례 연구

프로젝트 관리 시스템을 대상으로 하는 사례 연구

프로젝트 생명주기 초기의 기능 점수 계산 연습을
위한 사례 연구
기능 점수 분석 (Function Point Analysis)
200
기초적인 사례 연구: 문제 A

기능 점수 강좌에 관심이 있는 기업에 관한 정보를 유지하기 위한 간단한
어플리케이션을 구축하려고 한다. Company contact data의 논리적인 그룹은
다음 데이터 필드를 포함한다.
•




Company, Name of contact, Job title, Date of initial contact, Street address, City, State,
Zip code, Phone number, Fax number
이 데이터는 초기에 생성된다. 담당 직원은 온 라인 화면상에서 create, update,
delete 명령을 이용하여 임의의 정보를 생성, 변경, 삭제할 수 있다. create와
update 기능은 열 개의 모든 필드를 유지하고 delete 기능은 company와 name of
contact 만을 필요로 한다.
Company contact data에 포함되지만 별도의 트랜잭션으로 갱신되는 추가
필드는 Date packet sent, Date of phone contact, Notes이다.
이 필드들은 다음의 두 개의 별도 기본 프로세스에 의해 유지된다. (1) 정보
패킷이 전송될 때, 패키지를 우송(mailing)하는 개인은 기능 키를 이용하여
Company, Name of contact, Date packet sent를 별도의 화면에서 입력한다. (2)
우송 후 2주 이내에 수령을 확인하고 문의에 답하기 위해 전화를 걸어야 한다. 이
계약이 완료될 때, 전화를 건 사람은 기능 키를 이용하여 Company, Name of
contact, Date of phone contact, Notes를 입력하기 위해 별도의 화면을 이용할
것이다.
Date of phone contact은 정보가 여러 번 나타나는 정보를 저장하고 company
contact data를 갱신하기 위해 2차 키(두 번째 레코드 타입)로 사용될 것이다.
기능 점수 분석 (Function Point Analysis)
201
기초적인 사례 연구: 문제 A

메뉴 중심(menu-driven)의 시스템이 요구된다. 선택할 수 있는 기능은 다음과
같다.
• Create company contact
• Retrieve company contact
• Update company contact
• Delete company contact
• Packet sent
• Phone contact completed

Company, Name of contact, 기능 키를 이용한(prompted) 검색은 Company
contact data에 유지되는 모든 필드들을 디스플레이한다.
임의의 트랜잭션에 관한 에러들은 외부에서 유지되고 4개의 필드를 가지는 Error
file로부터 리턴된다. 이 필드 중의 하나는 에러 메시지를 포함한다.


문제 A에 관한 각 기능과 복잡도를 식별하라.
기능 점수 분석 (Function Point Analysis)
202
기초적인 사례 연구: 문제 A (계속)
기능 점수 분석 (Function Point Analysis)
203
기초적인 사례 연구: 문제 B
문제 A에 관한 미조정된 기능 점수를 계산하기 위해, 앞에서 식별한
기능들과 일반 시스템 특성을 이용하여 기능 점수 계산 Worksheet를
완성하라.
Function Point Calculation Worksheet
Project Number Problem B
Project Name Locator Application
Type of Count: Development Project/Application Counting (circle one)
Phase of Count: Proposal/Requirements/Design/Code/Test/Delivery (circle one)
Date of Count
Counter’s Name
Function Levels
Components
External inputs
External outputs
External inquiries
Internal logical files
External interface files
Low
×3
×4
×3
×7
×5
Average
×4
×5
×4
× 10
×7
High
×6
×7
×6
× 15
× 10
Total
Total unadjusted Function Points (UFP) =
기능 점수 분석 (Function Point Analysis)
204
기초적인 사례 연구: 문제 B (계속)
General System Characteristics
Degree of
Characteristic
Influence
1. Data communications
4
2. Distributed data processing
0
3. Performance
0
4. Heavily used configuration
0
5. Transaction rate
0
6. Online data entry
5
7. End user efficiency
3
Characteristic
8. Online update
9. Complex processing
10. Reusability
11. Installation ease
12. Operational ease
13. Multiple sites
14. Facilitate change
Degree of
Influence
3
1
3
1
3
1
2
Total degree of influence (TDI) =
VAF
FP
Value adjustment factor
=
Adjusted function point count =
(TDI × 0.01) + 0.65 =
UFP × VAF
=
기능 점수 분석 (Function Point Analysis)
205
프로젝트 관리 사례 연구:
트랜잭션 기능

기술(skill sets)을 정의하고, 기술을 가진 직원을 임명하고, 업무를 입력하고,
직원을 업무에 배정하는 것이 가능한 어플리케이션을 가정하자.

트랜잭션 기능
1. 사용자들은 외부에서 유지되는 Security 파일을 이용하여 패스워드를 검증하여
어플리케이션에 로그 온 한다.
2. 필드 수준의 도움말(HELP)은 외부에서 유지되는 Help 파일로부터 각 스크린 상의
각 필드에 대해 활용 가능하다.
3. 에러 메시지와 확인 메시지는 모든 스크린 트랜잭션에 대해 제공되고, 메시지는
하드 코드되어 사용자가 유지할 수 없다.
4. 코맨드 키가 모든 스크린 트랜잭션을 시작하기 위해 요구된다.
5. Skill Sets 파일이 추가, 갱신, 뷰 트랜잭션과 함께 유지된다. 삭제 기능은 존재하지
않는다. Skill Sets 파일의 모든 필드들은 추가, 갱신, 뷰 트랜잭션에 관한
스크린을 통해 활용 가능하다.
6. Task coordinator는 수행될 작업을 스크린 상에 입력한다. Tasks to Be Performed
파일에 있는 모든 필드들은 완성되어야 하고, 임의의 적절한 필드들이 또한
Location 파일과 Skill Sets 파일에 대해 검증된다. 수행될 각 업무는 유일한 ID를
가진다.
기능 점수 분석 (Function Point Analysis)
206
프로젝트 관리 사례 연구:
트랜잭션 기능
7. drop-down 리스트 박스가 업무의 우선순위(urgent, important, average, low) 를
하드 코드 테이블로부터 디스플레이한다.
8. Tasks to Be Performed 파일로부터의 모든 정보를 포함하는 뷰(view) 기능이 활용
가능하다.
9. 수행될 업무들이 배정되지 않으면, 수정되거나 삭제될 수 있다. Assignment
파일은 업무가 배정되었는가의 여부를 판단하기 위해 참조되어야 한다. 수정,
변경을 위해 적절한 필드가 Location 파일과 Skill Sets 파일에 대해 검증된다.
10. 배정 담당자(assignment clerk)는 업무의 우선순위에 기초하여 적절한 skill sets을
보유한 직원을 배정한다. Assignment 파일은 Personnel 파일(외부에서 유지되는
파일)과 Tasks to Be Performed 파일에 대해 검증되어 생성된다.
11. 배정 담당자(assignment clerk)는 Tasks to Be Performed 파일로부터의 모든
필드와 함께 배정되지 않은 업무를 검색하고 디스플레이한다. 디스플레이는 업무
우선순위, skill set ID, task location ID, 요청된 시작 날짜에 의해 정렬된다.
리스트는 동일한 필드를 가지고 프린트될 수 있고, 프린트된 리스트도
우선순위(urgent, important, average, low)에 의한 전체 작업을 포함한다.
12. 배정 담당자(assignment clerk)는 특정 skill sets, 특정 사무실 위치를 가진 사람과
그들을 활용할 수 있는 날짜(다음 배정 가능 날짜)를 검색한다. 리턴 스크린
디스플레이는 사람의 이름, skill sets, 사무실 위치, 다음 배정 가능한 날짜를
포함한다.
기능 점수 분석 (Function Point Analysis)
207
프로젝트 관리 사례 연구:
트랜잭션 기능
13. 만일 업무가 시작되지 않으면 배정은 삭제될 수 있다. 배정 날짜는 수정되거나
갱신될 수 없다.
14. 직원은 이름과 task ID와 함께 배정 완료 날짜를 입력하기 위해 시스템에
접근해야 한다. 단지 Assignment 파일만이 검증되고 갱신된다.
15. 현재 배정된(완료된 것으로 기록되지 않는) 모든 업무를 포함하는 별도의
리포트가 날마다 생성된다. 리포트는 사람의 이름, 시작될 날짜 배정, Assignment
파일로부터 완료될 것으로 기대되는 날짜 배정뿐만 아니라 Tasks to Be
Performed 파일로부터의 모든 필드를 포함한다.
16. 사무실의 감독자와 개인(개인의 이름)에게 배정된 업무(task ID), task location,
시작할 날짜 배정을 조정하는 모든 task coordinators에게 내부적으로 전자 우편
메시지가 생성된다. 전자 우편 주소는 Location 파일로부터 검색된다.
17. 업무, 언급된 사람의 이름, 전자 우편 주소, task ID, 업무 경과 날짜, task location
ID, 모든 location 정보, 요청된 skill set ID, skill set의 서술을 담은 전자 우편이
배정된 사람에게 보내진다.
기능 점수 분석 (Function Point Analysis)
208
프로젝트 관리 사례 연구:

데이터 기능
데이터 기능: 모든 파일과 그들에 관련된 필드들과 기본 키(primary key)는 다음과
같이 식별된다.
1. Tasks to Be Performed 파일
•
Task ID (unique, nonrepeating ID); PK
•
Task priority (urgent, important, average, low)
•
Task location ID
•
Skill set IDs required (up to two; no special priority or sequence)
•
Requested start date
•
Duration of task in days
2. Assignment 파일
•
Person's name: PK
•
Task ID; PK
•
Date assignment is to commence
•
Date assignment is expected to be complete (calculated and maintained
internally)
•
Next assignment date expected to be available (calculated and maintained
internally)
•
Assignment completion date (entered by employee)
기능 점수 분석 (Function Point Analysis)
209
프로젝트 관리 사례 연구:
데이터 기능(계속)
3. Skill Sets 파일
•
Skill set ID; PK
•
Skill set description
•
Licensing requirement
•
Educational requirement
•
Local training requirement
•
Suggested corollary skill set IDs (up to three)
4. Personnel 파일 (외부에서 유지됨)
•
Person's name; PK
•
Skill sets IDs (up to five skills possible)
•
Office location
•
E-mail address
5. Help 파일 (외부에서 유지됨)
•
Screen ID; PK
•
Field ID; PK
•
Help text (up to six lines possible)
기능 점수 분석 (Function Point Analysis)
210
프로젝트 관리 사례 연구:
데이터 기능(계속)
6. Security 파일
•
Log-on user ID; PK
•
Password
•
Application authorization
7. Location 파일 (외부에서 유지됨)
•
Location ID; PK
•
Street address (three lines)
•
City
•
State
•
Zip code
•
Office phone number
•
Office supervisor's name
•
Office supervisor's e-mail address
•
Task coordinator's name
•
Task coordinator's e-mail address

제공된 정보를 기초로 데이터 기능과 트랜잭션 기능의 복잡도를
식별하라.
기능 점수 분석 (Function Point Analysis)
211
초기 정의 단계에서 기능 점수 계산

직원과 방문객 모두를 위한 주차 공간 배정을 할당, 유지, 보고서를
생성하는 주차 공간 배정 어플리케이션 (Parking Assignment
application) 을 구축하기로 결정했다고 가정하자. Joint Application
Design (JAD)을 이용하여 새로운 어플리케이션이 개발되고, Building
Personnel 어플리케이션에서 유지되는 Personnel 파일로부터 참조
데이터가 검색된다.

트랜잭션 기능
1. 미배정된 모든 주차 공간을 조사(view).
2. 주차장을 찾은 직원을 Personnel 파일로부터 first, middle, last name을 이용하여
검색(look up)
3. 방문객에게 주차 공간을 배정, 주차장을 찾은 직원을 Personnel 파일에서 검증
4. 방문객 예약 주차 공간을 폐쇄
5. 주차 공간을 배정 받은 현재의 방문객을 Personnel 파일로부터 직원 정보와 함께
조사(view)
기능 점수 분석 (Function Point Analysis)
212
초기 정의 단계에서 기능 점수 계산(계속)
6. 근무 종료 시간(end of day)에 방문객 보고서를 Parking Assignment 파일과
Personnel 파일 모두로부터의 정보, 방문객 총 수와 함께 생성
7. 직원에게 영구 주차 공간을 배정, Personnel 파일로 검증
8. 직원의 영구 주차 공간을 전환, Personnel 파일로 검증
9. 직원에게 배정된 영구 주차 공간을 폐쇄
10. 영구 주차 공간 배정에 관한 주간 보고서를 Parking Assignment 파일과
Personnel 파일 모두로부터의 정보, 합계와 함께 생성
11. 유지보수를 위해 폐쇄된 주차 공간을 표시
12. 유지보수를 위해 폐쇄된 주차 공간을 조사(view)
13. 유지보수를 위해 폐쇄된 주차 공간을 다시 개방
14. 유지보수에 관한 주간 보고서를 전체 내용과 함께 생성
기능 점수 분석 (Function Point Analysis)
213
초기 정의 단계에서 기능 점수 계산(계속)

총 12개의 방문객 주차 공간과 144개의 직원용 영구 주차공간이
존 재 한 다 . 앞 에 서 언 급 한 것 처 럼 , 데 이 터 는 Building Personnel
어플리케이션에서 유지되는 Personnel 파일로부터 검색되고 참조되는
것으로 결정된다. 예상되는 데이터는 다음과 같다.

데이터 기능
Personnel 파일
•
First name (한 개의 필드로 고려)
•
Middle name (한 개의 필드로 고려)
•
Last name (한 개의 필드로 고려)
•
Employee ID
•
Office phone number
•
Office location
기능 점수 분석 (Function Point Analysis)
214
초기 정의 단계에서 기능 점수 계산(계속)
Parking Assignment 파일
서브그룹 1: Visitor space number (V1-V12)
•
•
•
•
•
•
•
•
Date
Time assigned
Time out
Visitor's name
ID of employee being visited
Space closed for maintenance (Y/N)
Date closed for maintenance
Date reopened
서브그룹 2: Employee space number (P1-P144)
•
Date effective
Name: first, middle, last (전체 이름이 한 개의필드로 고려)
Employee ID
Date space released
Space closed for maintenance
Date closed for maintenance
Date reopened

데이터 기능과 트랜잭션 기능을 식별하고 복잡도를 추정하라.
•
•
•
•
•
•
기능 점수 분석 (Function Point Analysis)
215
참고문헌

International Function Point Users Group. Function Point
Counting Practices Manual, Release 4.1. Westerville, OH:
IFPUG Standards, 1999.

David Garmus and David Herron. Function Point Analysis:
Measuring Successful Software Projects, Reading, MA:
Addison-Wesley, 2001.

David Garmus and David Herron. Measuring Software Process:
A Practical Guide to Functional Measurements, Englewood
Cliffs, NJ: Prentice-Hall, 1995.

J. Brian Dreger. Function Point Analysis, Englewood Cliffs, NJ:
Prentice-Hall, 1989.
기능 점수 분석 (Function Point Analysis)
216
6-1
사례 연구의 답


문제 A
문제 B
기능 점수 분석 (Function Point Analysis)
217
사례 연구: 문제 A





기능 점수 강좌에 관심이 있는 기업에 관한 정보를 유지하기 위한 간단한
어플리케이션을 구축하려고 한다. Company contact data의 논리적인 그룹은
다음 데이터 필드를 포함한다. (10개)
이 데이터는 초기에 생성된다. 담당 직원은 온 라인 화면상에서 create, update,
delete 명령을 이용하여 임의의 정보를 생성, 변경, 삭제할 수 있다. create와
update 기능은 열 개의 모든 필드를 유지하고( DET 12(10+2:에러 메시지,
메뉴), FTR 2(Company contact data, Error file)), delete 기능은 company와
name of contact 만을 필요로 한다( DET 4(2+2:에러 메시지, 메뉴), FTR
2(Company contact data, Error file)).
Company contact data에 포함되지만 별도의 트랜잭션으로 갱신되는 추가
필드는 Date packet sent, Date of phone contact, Notes이다.  DET 13(10+3)
이 필드들은 다음의 두 개의 별도 기본 프로세스에 의해 유지된다. (1) 정보
패킷은 별도의 화면에서 기능 키를 이용하여 Company, Name of contact, Date
packet sent를 입력하여 전송된다.  DET 5(3:Company, Name of contact, Date
of phone contact+2:에러 메시지, 메뉴), FTR 2(Company contact data, Error file)
(2) 전화를 이용한 계약은 별도의 화면에서 기능 키를 이용하여 Company, Name
of contact, Date of phone contact, Notes 를 입 력하 여 완 성 된 다 .  DET
6(4:Company, Name of contact, Date of phone contact, Notes+2:에러 메시지,
메뉴), FTR 2(Company contact data, Error file)
Date of phone contact은 company contact data( RET 2)를 갱신하기위해 2차
키(두번째 레코드 타입)로 사용된다.
기능 점수 분석 (Function Point Analysis)
218
사례 연구: 문제 A (계속)

메뉴에서 선택할 수 있는 기능은 다음과 같다.
• Create company contact
• Retrieve company contact
• Update company contact
• Delete company contact
• Packet sent
• Phone contact completed

Company, Name of contact, 기능 키를 이용한(prompted) 검색은 Company
contact data 에 유 지 되 는 모 든 필 드 들 을 디 스 플 레 이 한 다 .  DET
15(10+3(Company, Name of contact, 기능 키)+2(에러 메시지, 메뉴), FTR 2
(Company contact data, Error file)
임의의 트랜잭션에 관한 에러들은 외부에서 유지되고, 4개의 필드를 가지는 Error
file 로부터 리턴된다. 이 필드중의 하나는 에러 메시지를 포함한다.  DET 4,
RET 1(Primary key)


문제 A에 관한 각 기능과 복잡도를 식별하라.
기능 점수 분석 (Function Point Analysis)
219
사례 연구: 문제 A (계속)
기능 점수 분석 (Function Point Analysis)
220
사례 연구: 문제 A





기능 점수 강좌에 관심이 있는 기업에 관한 정보를 유지하기 위한 간단한
어플리케이션을 구축하려고 한다. Company contact data의 논리적인 그룹은
다음 데이터 필드를 포함한다. (10개)
이 데이터는 초기에 생성된다. 담당 직원은 온 라인 화면상에서 create, update,
delete 명령을 이용하여 임의의 정보를 생성, 변경, 삭제할 수 있다. create와
update 기능은 열 개의 모든 필드를 유지하고( DET 12(10+2:에러 메시지,
메뉴), FTR 2(Company contact data, Error file)), delete 기능은 company와
name of contact 만을 필요로 한다( DET 4(2+2:에러 메시지, 메뉴), FTR
2(Company contact data, Error file)).
Company contact data에 포함되지만 별도의 트랜잭션으로 갱신되는 추가
필드는 Date packet sent, Date of phone contact, Notes이다.  DET 13(10+3)
이 필드들은 다음의 두 개의 별도 기본 프로세스에 의해 유지된다. (1) 정보
패킷은 별도의 화면에서 기능 키를 이용하여 Company, Name of contact, Date
packet sent를 입력하여 전송된다.  DET 5(3:Company, Name of contact, Date
of phone contact+2:에러 메시지, 메뉴), FTR 2(Company contact data, Error file)
(2) 전화를 이용한 계약은 별도의 화면에서 기능 키를 이용하여 Company, Name
of contact, Date of phone contact, Notes 를 입 력하 여 완 성 된 다 .  DET
6(4:Company, Name of contact, Date of phone contact, Notes+2:에러 메시지,
메뉴), FTR 2(Company contact data, Error file)
Date of phone contact은 company contact data( RET 2)를 갱신하기위해 2차
키(두번째 레코드 타입)로 사용된다.
기능 점수 분석 (Function Point Analysis)
221
사례 연구: 문제 A (계속)

메뉴에서 선택할 수 있는 기능은 다음과 같다.
• Create company contact
• Retrieve company contact
• Update company contact
• Delete company contact
• Packet sent
• Phone contact completed

Company, Name of contact, 기능 키를 이용한(prompted) 검색은 Company
contact data 에 유 지 되 는 모 든 필 드 들 을 디 스 플 레 이 한 다 .  DET
15(10+3(Company, Name of contact, 기능 키)+2(에러 메시지, 메뉴), FTR 2
(Company contact data, Error file)
임의의 트랜잭션에 관한 에러들은 외부에서 유지되고, 4개의 필드를 가지는 Error
file 로부터 리턴된다. 이 필드중의 하나는 에러 메시지를 포함한다.  DET 4,
RET 1(Primary key)


문제 A에 관한 각 기능과 복잡도를 식별하라.
기능 점수 분석 (Function Point Analysis)
222
사례 연구: 문제 A (계속)
기능 점수 분석 (Function Point Analysis)
223
기초적인 사례 연구: 문제 B
문제 A에 관한 미조정된 기능 점수를 계산하기 위해, 앞에서 식별한
기능들과 일반 시스템 특성을 이용하여 기능 점수 계산 Worksheet를
완성하라.
Function Point Calculation Worksheet
Project Number Problem B
Project Name Locator Application
Type of Count: Development Project/Application Counting (circle one)
Phase of Count: Proposal/Requirements/Design/Code/Test/Delivery (circle one)
Date of Count
Counter’s Name
Function Levels
Components
External inputs
External outputs
External inquiries
Internal logical files
External interface files
Low
1×3
×4
×3
1×7
1×5
Average
4×4
×5
1×4
× 10
×7
High
×6
×7
×6
× 15
× 10
Total
19
0
4
7
5
Total unadjusted Function Points (UFP) = 35
기능 점수 분석 (Function Point Analysis)
224
기초적인 사례 연구: 문제 B (계속)
General System Characteristics
Degree of
Characteristic
Influence
1. Data communications
4
2. Distributed data processing
0
3. Performance
0
4. Heavily used configuration
0
5. Transaction rate
0
6. Online data entry
5
7. End user efficiency
3
Characteristic
8. Online update
9. Complex processing
10. Reusability
11. Installation ease
12. Operational ease
13. Multiple sites
14. Facilitate change
Degree of
Influence
3
1
3
1
3
1
2
Total degree of influence (TDI) = 26
VAF
FP
Value adjustment factor
=
Adjusted function point count =
(TDI × 0.01) + 0.65 = 0.91
UFP × VAF
= 31.85
기능 점수 분석 (Function Point Analysis)
225