(Function Point Analysis)

(Function Point Analysis)
기능 점수 분석 (Function Point Analysis)

차 례 1. 기능 점수 분석 개요 2. 데이터 기능의 크기 측정 3. 트랜잭션 기능의 크기 측정 4. 일반 시스템 특성
차 례 1. 기능 점수 분석 개요 2. 데이터 기능의 크기 측정 3. 트랜잭션 기능의 크기 측정 4. 일반 시스템 특성 5. 기능 점수의 계산과 응용 6. 사례 연구

배경 기능 점수 계산 과정 기능 점수의 유형 계산 범위와 어플리케이션의 경계
1 기능 점수 분석 개요 배경 기능 점수 계산 과정 기능 점수의 유형 계산 범위와 어플리케이션의 경계

배경 기능 점수 분석(Function Point Analysis: FPA)은 소프트웨어 개발 프로젝트 혹은 설치된 소프트웨어 어플리케이션의 크기를 측정하는 방법론 FPA는 이미 검증되었고, 미국, 영국, 호주, 오스트리아, 브라질, 덴마크, 독일, 이탈리아, 일본, 네덜란드, 남아프리카 공화국 등을 비롯한 세계 각국에서 일반적으로 널리 받아들여진 방법론 FPA는 새로운 기술들의 발전과 동시에 재검토되고, 분명해졌으며, 갱신되고 있음 일관성 향상되고 어플리케이션의 크기와 노력간의 관련성이 개선 최근의 기준은 IFPUG 계산 실무 위원회에서 발표한 지침서(Counting Practices Manual) 버전 4.1

배경 (계속) FPA는 소프트웨어 크기를 측정하기 위해 일반적으로 인정된 표준 FPA는 비용 산정 과정 초기에 도입될 수 있음
기능 점수로 측정한 크기는 어플리케이션 속성(성능, 보안성 등)과 프로젝트 속성(기술 수준, 언어, 방법론 등)과 함께 사용 기능 점수는 영역이 변경되거나 개발 과정의 새로운 단계가 시작될 때마다 다시 계산되어야 함 기능 점수는 사용자가 요구하는 기능을 표현해야 하므로 초기에 기능 분석이 가능하고 의미가 있음 프로젝트 제안 단계 초기에 이해당사자가 함께 모이는 것이 개발 작업을 쉽게 하고 사용자가 실제 원하는 것을 분명하게 할 수 있음 소프트웨어 기능의 계량화를 위해 개발 단계와 유지 보수 단계에서 적용

기능 점수 계산 과정 1. 기능 점수의 유형 결정 2. 기능 점수 계산 범위와 어플리케이션 경계를 식별
3. 데이터 기능(내부 논리 파일, 외부 인터페이스 파일)과 복잡도 계산 4. 트랜잭션 기능(외부 입력, 외부 출력, 외부 조회)과 복잡도 계산 5. 미조정된 기능 점수(unadjusted function point) 계산 6. 일반 시스템 특성에 근거한 값 조정 인자 계산 7. 조정된 기능 점수(adjusted function point) 계산

기능 점수 계산 과정 (계속) 기능 점수의 유형 기능 점수 계산 범위와 어플리케이션 경계를 식별
개발 프로젝트 기능 점수 확장 프로젝트 기능 점수 어플리케이션 기능 점수 기능 점수 계산 범위와 어플리케이션 경계를 식별 계산 범위는 크기를 측정하기 원하는 범위 어플리케이션의 경계는 측정되는 어플리케이션과 다른 독립적인 어플리케이션을 구분 데이터 기능(내부 논리 파일, 외부 인터페이스 파일)과 복잡도 계산 데이터 기능은 갱신과 검색을 위해 저장되어 활용 가능한 논리 데이터와 파일 트랜잭션 기능(외부 입력, 외부 출력, 외부 조회)과 복잡도 계산 트랜잭션 기능은 데이터의 유지보수, 검색, 출력 등을 수행

기능 점수 계산 과정의 예 예: 각 직원의 근무 위치 정보를 유지하고 디스플레이하는 Location 어플리케이션
Clerk Building Security Location Listing Personnel Employee Data Location Directory Data update directory determine if employee print monthly listing request, retrieve, display information from Location and Personnel

기능 점수 계산 준비 예: 각 직원의 근무 위치 정보를 유지하고 디스플레이하는 Location 어플리케이션
단계 1. 기능 점수 유형 개발 이력에 상관 없이 현재의 어플리케이션을 계산하므로 기능 점수의 유형은 어플리케이션 기능 점수 단계 2. 계산 범위와 어플리케이션 경계 범위: 어플리케이션에 존재하는 모든 기능 경계: Location, Location Listing, Clerk, Building Security, Personnel

기능 점수 계산 준비 단계 3. 데이터 기능 (ILF, EIF) 단계 4. 트랜잭션 기능 (EI, EO, EQ)
내부 논리 파일(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 내에 유지되는 정보의 검색과 디스플레이

기능 점수 계산에 유용한 정보 개발의 초기 단계에서 활용할 수 있는 정보의 양은 적지만, 개발이 진행됨에 따라 활용할 수 있는 정보의 양이 많아짐 유용한 정보를 얻을 수 있는 문서의 종류 프로젝트 제안서 고수준의 시스템 다이어그램 ER 다이어그램 논리 데이터 모델 데이터 흐름도 객체 모델 프로세스 모델 요구 문서 프로토타입 기능 명세서 유스 케이스

기능 점수 계산에 유용한 정보 (계속) 유용한 정보를 얻을 수 있는 문서의 종류 (계속) 시스템 명세서 상세 설계 명세서
물리 설계 모델 운영 모델 프로그램과 모듈 명세서 파일 배치도 데이터베이스 배치도 스크린 출력 리포트 배치도 테스트 케이스 사용자 매뉴얼과 기술 문서 시스템 도움말(help)

기능 점수의 유형 개발 프로젝트 기능 점수 처음 설치된 어플리케이션을 통해 사용자에게 제공되는 기능을 측정
초기의 어플리케이션 기능 점수로 계산되는 기능과 데이터 컨버전을 위해 필요한 기능 포함 Location 어플리케이션을 새로 개발되는 어플리케이션으로 대치하면, 새로운 어플리케이션이 제공하는 기능 뿐만 아니라 예전 데이터 파일의 데이터를 새로운 데이터 파일로 변환하는 컨버전 기능을 함께 계산 원점에서 시작하는 계산이 아니라 이전에 인식된 기능을 검증하여 기능을 추가하는 연속적인 기능 점수 계산 프로젝트 개발 동안의 계산 Requirements Function Point Count Initial Design Detailed Coding Testing Implementation Maintenance

기능 점수의 유형 (계속) 확장 프로젝트 기능 점수 어플리케이션 기능 점수
새로운 기능의 추가, 예전 기능의 제거, 기존 기능의 변경을 포함하여 기존 어플리케이션을 수정하여 사용자에게 제공되는 기능 어플리케이션 기능 점수 설치된 어플리케이션이 최종사용자에게 제공하는 현재의 기능 현재 활용되고 유지되는 어플리케이션의 기능 점수 기준선(baseline)에 해당

계산 범위와 어플리케이션의 경계 기능 점수의 계산 범위는 목적에 의해 결정
크기를 측정하기 원하는 범위 크기를 측정할 시스템, 어플리케이션, 어플리케이션의 부분 집합 상용 패키지의 구입, 아웃소싱 어플리케이션, 특정 목적의 어플리케이션의 기능 포함 어플리케이션의 경계는 측정되는 어플리케이션과 외부 어플리케이션 혹은 사용자 영역 사이의 경계 측정되는 어플리케이션과 다른 독립적인 어플리케이션 혹은 사용자 영역을 구분

기능 점수 계산을 위한 구성 요소 External User Application Boundary
Input Inquiry Output Internal Logical File Interface File External Input External Output Application Boundary Other Applications

어플리케이션 경계를 식별하는 규칙 어플리케이션 경계는 사용자 뷰(user’s view)에 기반을 둠
사용자의 언어로 어플리케이션의 범위와 비즈니스 기능을 정의 관련된 어플리케이션 사이의 경계는 기술적 요소보다는 비즈니스 측면의 기능에 기초함 MS Office는 Word, Excel, PowerPoint, Access로 구성되고, 각각은 별도의 MS Office 내의 어플리케이션 확장 중인 어플리케이션에 대한 초기의 어플리케이션 경계는 확장과 함께 변경됨 추가된 기능은 경계를 확장시키고 삭제된 기능은 경계를 축소시킴 변경된 기능은 어플리케이션의 기능 점수의 크기를 변경시킬 수 있음 개발 프로젝트와 확장 프로젝트는 단일 어플리케이션 이상을 포함하고, 다중 어플리케이션의 경계는 계산 범위 내에 포함되지만 별도로 계산

Accounting System의 어플리케이션 경계
Accounts Receivable General Ledger Payable

Production System의 어플리케이션 경계
Shop Planner Material Inventory Work Schedule

개요 데이터 기능의 유형 ILF와 EIF의 복잡도 ILF와 EIF의 계산 예
2 데이터 기능의 크기 측정 개요 데이터 기능의 유형 ILF와 EIF의 복잡도 ILF와 EIF의 계산 예

개요 데이터 기능은 저장된 논리 데이터와 관련이 있으며 갱신, 참조, 검색을 위해 활용될 수 있음
데이터 기능은 내부 논리 파일(ILF)이나 외부 인터페이스 파일(EIF)로 식별되는데, 이들은 모두 논리적으로 관련된 데이터나 제어 정보의 그룹으로 사용자가 식별 가능해야 함 어플리케이션의 물리적 파일 구조의 구현에 관련 없이 ILF와 EIF의 수가 동일하게 식별되어야 함 Flat file, IDMS 데이터베이스, IMS 데이터베이스, 관계형 데이터베이스, DB2 테이블, 객체 ILF는 기능 점수를 측정하려고 하는 어플리케이션의 경계 내에서 유지됨 EIF는 기능 점수를 측정하려고 하는 어플리케이션의 경계 내에서 판독, 참조되지만 상이한 어플리케이션 경계 내에서 유지됨

데이터 기능을 먼저 계산하는 이유 1. 트랜잭션 기능의 복잡도를 계산하기 위해서는 어느 ILF와 EIF가 각 트랜잭션 기능에 의해 유지, 참조되는지 알아야 함. 각 데이터 기능과 트랜잭션 기능은 표준 행렬을 기초로 low, average, high 중의 하나로 가중치가 할당됨 2. 데이터베이스 파일을 먼저 식별하고, 다음에 트랜잭션 기능을 식별함에 따라 이전에 ILF와 EIF로 지정한 것이 타당하지 검증할 수 있음 Location 어플리케이션(예)에서 ILF인 Location Directory Data는 어플리케이션의 경계 내에서 유지됨 EIF인 Employee Data는 Personnel 어플리케이션의 경계 내에서 유지되고 데이터의 참조를 위해 Location 어플리케이션에서 이용됨 그 결과로 ILF로 계산되는 데이터의 논리적 그룹은 Location 어플리케이션 내에서 최소한 하나의 외부 입력(EI)에 의해 갱신되거나 유지되어야 함

데이터 기능의 유형 ILF와 EIF 개요 1. 내부 논리 파일(ILF) 2. 외부 인터페이스 파일(EIF)
ILF는 EI, EO, EQ에 의해 읽히거나 참조되어야 함 ILF는 대개 기능 점수를 계산 중인 어플리케이션에서 항상 읽히거나 참조되지만, 다른 어플리케이션 내에서 읽히거나 참조될 수 있음 2. 외부 인터페이스 파일(EIF) EIF가 다른 어플리케이션에서 유지된다고 하더라도 논리적인 그룹의 일부 데이터는 기능 점수를 계산 중인 어플리케이션 내에서 최소한 하나의 EI, EO, EQ에 의해 읽히거나 참조되어야 함 데이터는 편집, 디스플레이, 계산, 비교를 위한 검색시 읽히거나 참조됨

데이터 기능의 유형: ILF 정의: ILF는 어플리케이션의 경계 내에서 유지되는 논리적으로 관련된 데이터나 제어 정보로 사용자가 식별 가능한 그룹 의미: 기능 점수를 계산 중인 어플리케이션의 하나 이상의 기본적인 프로세스를 통해 유지되는 데이터 사용자가 식별 가능하다는 것은 사용자와 소프트웨어 개발자 모두가 이해하고 동의한 요구사항, 데이터 그룹 예: financial application의 checking account record

데이터 기능의 유형: ILF (계속) 정의 논리적으로 관련된다는 것은 각 그룹이 논리적으로 적합해야 한다는 요구조건
ILF는 다른 ILF에 종속되거나 한정되지 않아야 함 성능이나 구현 상의 이유로 생성된 그룹들은 합병되어야 함 제2정규형이나 제3정규형의 엔터티 타입 데이터 흐름도(Data Flow Diagram)의 데이터 저장소(Data Store)에 해당 예: 주소 테이블은 고객 파일, 거래 파일, 재고품 위치 파일, 직원 파일과 같은 논리적 그룹에 해당

데이터 기능의 유형: ILF (계속) 정의 데이터는 어플리케이션 내에서 유지되는 사실(facts), 수(figures) 등의 모임 check number, amount, date, payee, memo entry, account number는 checking account record 내에 유지됨 제어 정보는 어플리케이션의 기본 프로세스에 영향을 주기 위해 어플리케이션에 의해 이용되는 데이터 어떤 데이터가 언제 어떻게 처리되는지를 규정 예: Printer Manager 내에 유지되는 제어 데이터, 부정확하거나 부적절한 데이터를 거부하기 위한 편집 데이터, 이벤트의 순서와 타이밍을 설정하는 날짜와 시간, 이벤트를 제어하기 위한 threshold

데이터 기능의 유형: ILF (계속) 정의 유지(maintain)된다는 것은 어플리케이션의 기본 프로세스 동안 데이터가 수정된다는 사실을 의미 데이터와 제어 정보를 유지하는 트랜잭션의 예: add, bill, change, delete, evaluate, fail, grant, hold, populate, revise, update ILF는 여러 어플리케이션에 의해 유지되거나 ILF로서 계산될 수 있지만, 어플리케이션 당 하나로 계산됨 기본 프로세스는 사용자에게 의미 있는 가장 작은 작업 단위 창고에서 물건을 출하(issue)하는 것은 CRUD 서브 프로세스로 분할될 수 있으나, 출하가 기본 프로세스 동일 트랜잭션으로 여러 ILF 갱신 가능

IFPUG의 ILF 계산 규칙 데이터나 제어 정보의 그룹은 논리적이고 사용자가 식별 가능하다.
데이터 그룹은 기능 점수가 계산되는 어플리케이션의 경계 내에서 기본 프로세스를 통해 유지된다. 데이터 그룹은 어플리케이션 내에서 일단 ILF로 식별되고 나면, 비록 다른 트랜잭션에 의해 참조 목적으로 이용된다고 해도 동일한 어플리케이션 내에서 또 다시 EIF로 계산될 수 없고, 그 어플리케이션의 확장 프로젝트에서도 EIF로 계산될 수 없음

ILF의 공통적인 예 어플리케이션 트랜잭션 데이터
transaction issue record, employee training record, payroll record, credit card transaction, product sales, customer call, accounts payable 어플리케이션 내에서 유지되는 보안(security) 데이터 혹은 패스워드 데이터 어플리케이션 내에서 유지되는 HELP 데이터 어플리케이션 내에서 유지되는 Edit 데이터 어플리케이션 내에서 유지되는 Parameter 데이터 어플리케이션 내에서 유지되는 에러 파일과 에러 기술(description)

ILF로 잘못 식별되는 예 임시 파일이나 다양하게 반복되는 동일한 파일 작업 파일 정렬 파일
디스플레이나 프린트에 앞서서 다른 ILF나 EIF에서 추출된 데이터를 포함하는 extract file 혹은 view file EO나 EQ를 생성하는데 필요한 파일의 일부 기술적인 이유로 도입된 파일 동일한 파일의 사본 별도로 유지되는 대치 색인(alternative index), 조인(join), 관계(relationship) 감사(audit) 데이터나 이력 데이터 어플리케이션 트랜잭션 데이터에서 함께 계산되어야 함

ILF로 잘못 식별되는 예 (계속) 다른 어플리케이션 내에서 유지되거나 단지 읽히거나 참조되기만 하는 파일
EIF로 계산되어야 함 공동의 백업과 복구를 위해 이용되는 백업 데이터 일반 시스템 특성(GSC)에서 인식됨 별도로 유지되지 않는, 불완전한 트랜잭션을 포함하는 서스펜스 파일

데이터 기능의 유형: EIF 정의: EIF는 어플리케이션에 의해 참조되지만 상이한 어플리케이션의 경계 내에서 유지되는 논리적으로 관련된 데이터나 제어 정보로 사용자가 식별 가능한 그룹 의미: 기능 점수를 계산 중인 어플리케이션의 하나 이상의 기본적인 프로세스를 통해 참조되는 데이터 사용자가 식별 가능하다는 것은 사용자와 소프트웨어 개발자 모두가 이해하고 동의한 요구사항, 데이터 그룹 예: financial application의 checking account record는 관계 없는 데이터를 검증하는 동안에만 읽힘

데이터 기능의 유형: EIF (계속) 정의 논리적으로 관련된다는 것은 각 그룹이 논리적으로 적합해야 한다는 요구조건
EIF는 다른 EIF에 종속되거나 한정되지 않아야 함 성능이나 구현 상의 이유로 생성된 그룹들은 합병되어야 함 제2정규형이나 제3정규형의 엔터티 타입 데이터 흐름도(Data Flow Diagram)의 데이터 저장소(Data Store)에 해당 예: 주소 테이블은 고객 파일, 거래 파일, 재고품 위치 파일, 직원 파일과 같은 논리적 그룹에 속함

데이터 기능의 유형: EIF (계속) 정의 데이터는 또 다른 어플리케이션 내에서 유지되는 사실(facts), 수(figures) 등의 모임 check number, amount, date, payee, memo entry, account number는 checking account record 내에 유지됨 제어 정보는 어플리케이션의 기본 프로세스에 영향을 주기 위해 어플리케이션에 의해 이용되는 데이터 어떤 데이터가 언제 어떻게 처리되는지를 규정 예: Printer Manager 내에 유지되는 제어 데이터는 PowerPoint에 의해 읽힘, 부정확하거나 부적절한 데이터를 거부하기 위한 편집 데이터의 참조, 이벤트의 순서와 타이밍을 설정하는 날짜와 시간이 읽히거나 참조, 이벤트를 제어하기 위한 threshold의 설정

데이터 기능의 유형: EIF (계속) 정의 유지(maintain)된다는 것은 어플리케이션의 기본 프로세스 동안 데이터가 수정된다는 사실을 의미 기본 프로세스는 사용자에게 의미 있는 가장 작은 작업 단위 창고에서 물건의 스크린 디스플레이는 다양한 서브 프로세스로 분할 될 수 있으나, 물건의 양을 판단하기 위해 하나의 파일이 읽히고 별도의 파일은 물건의 내역을 참조하기 위해 읽힘 창고에서 물건을 출하(issue)하는 것은 기본 프로세스 동일 트랜잭션으로 여러 EIF 갱신 가능

IFPUG의 EIF 계산 규칙 데이터나 제어 정보의 그룹은 논리적이고 사용자가 식별 가능
데이터 그룹은 계산 중인 어플리케이션에 의해 참조되지만, 외부에 있음 데이터 그룹은 계산 중인 어플리케이션에 의해 유지되지 않음 데이터 그룹은 또 다른 어플리케이션에 의해 유지됨 데이터 그룹이 어플리케이션 내에서 일단 EIF로 식별되고 나면, 비록 다른 트랜잭션에 의해 참조 목적으로 이용된다고 해도, 동일한 어플리케이션 내에서 또 다시 EIF로 계산될 수 없음

EIF의 공통적인 예 다른 어플리케이션에서 추출되고 읽히는 데이터
어플리케이션 외부에서 유지되는 보안(security) 데이터 혹은 패스워드 데이터 어플리케이션 외부에서 유지되는 HELP 데이터 어플리케이션 외부에서 유지되는 Edit 데이터 어플리케이션 외부에서 유지되는 Parameter 데이터 어플리케이션 외부에서 유지되는 에러 파일과 에러 기술(description)

EIF로 잘못 식별되는 예 하나 이상의 ILF를 유지하는 또 다른 어플리케이션에서 계산 중인 어플리케이션 내부로 수신된 데이터
계산 중인 어플리케이션에 의해 유지되지만, 상이한 어플리케이션에 의해 접근되고 이용되는 데이터 상이한 어플리케이션에 대한 EIF로 계산되어야 함 계산 중인 어플리케이션에 의해 포맷되어 다른 어플리케이션으로 송신되는 데이터 EO나 EQ로 계산되어야 함 임시 파일이나 동일한 파일의 다양한 반복 작업 파일 정렬 파일

EIF로 잘못 식별되는 예 (계속) 디스플레이나 프린트에 앞서서 다른 ILF나 EIF에서 추출된 데이터를 포함하는 extract file 혹은 view file EO나 EQ를 생성하는데 필요한 파일의 일부 기술적인 이유로 도입된 파일 동일한 파일의 사본 별도로 유지되는 대치 색인(alternative index), 조인(join), 관계(relationship) 감사(audit) 데이터나 이력 데이터 어플리케이션 트랜잭션 데이터에서 함께 계산되어야 함

ILF와 EIF의 복잡도 ILF와 EIF의 개수와 각각의 기능 복잡도가 함께 기능 점수의 계산에 영향을 미친다. 식별된 각각의 ILF 와 EIF는 관련된 데이터 요소 타입(DET)과 레코드 요소 타입(RET)의 수를 기준으로 기능 복잡도가 결정된다. 기능 복잡도(functional complexity)는 DET와 RET의 개수에 따라 low, average, high 중 하나의 등급을 부여함 (복잡도 행렬에 정의) 데이터 요소 타입(DET)은 사용자가 인식 가능한, 유일하고, 반복되지 않는 필드나 속성 레코드 요소 타입(RET)은 ILF나 EIF 내에 포함된 데이터 요소들로 사용자가 인식 가능한 서브 그룹 (optional이나 mandatory) 서브 그룹은 ER 다이어그램에서 엔터티 서브 타입이나 속성 엔터티로 표현됨

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로 계산한다. 외래 키

DET counting example

DET에 관한 추가적인 정보 기술이나 구현상의 이유 때문에 ILF나 EIF 내에서 여러 번 나타나는 필드는 오직 한 번만 계산됨 포맷이 동일한 반복 필드는 ILF나 EIF 내에서 오직 한 번만 계산됨 12개의 월간 합계 필드와 하나의 년간 합계 필드는 두 개의 DET로 계산 이벤트가 발생한 시간을 기록하는 타임 스탬프는 하나의 DET로 계산됨 외부 입력(EI)을 처리하는 동안 내부에서 처리되어 데이터베이스에 저장되는 계산(calculation)은 하나의 DET로 간주됨

IFPUG의 RET 계산 규칙 ILF나 EIF의 선택적인 서브 그룹이나 필수적인 서브 그룹 각각을 하나의 RET로 계산한다.
논리 파일의 데이터는 전형적으로 제3정규형의 데이터 만일 서브 그룹이 존재하지 않으면, ILF나 EIF를 하나의 RET로 계산한다.

ILF나 EIF의 계산 예: 요구사항 직원 정보를 유지, 조회, 기록하는 기능이 필요. 생성된 리포트는 다른 어플리케이션에 의해 유지되는 파일에서 얻은 직원에 대한 위치 데이터를 포함. 업무 기술(job description)을 포함하는 업무 정보를 유지, 조회, 기록하는 기능이 필요. 직원에 대한 업무 배정(job assignment)을 유지, 조회, 기록하는 기능이 필요. 회사 내의 특정 위치에 있는 직원의 리스트를 포함한 위치 데이터(location data)에서 위치를 조회하고 기록하는 기능이 필요. 이 위치 데이터는 읽을 수만 있고 다른 어플리케이션에 의해서 유지됨.

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

프로세스 모델 (계속) 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

ILF나 EIF의 계산 예: ER 다이어그램 EMPLOYEE SALARIED_EMP JOB_ASSIGNMENT
LOCATION JOB_ASSIGNMENT JOB JOB_DESCRIPTION SALARIED_EMP HOURLY_EMP

관계형 데이터베이스 구조 EMPLOYEE LOC_ASSGMT LOCATION JOB JOB_DESC JOB_ASSIGNMENT
NAME SSN

IDMS 데이터베이스 구조 EMPLOYEE SALARIED HOURLY JOB LOCATION_ ASSGNMNT
DESCRIP

IMS 데이터베이스 구조 EMPLOYEE JOB LOCATION_ ASSGNMNT LOCATION JOB_ DESCRIP

엔터티 타입에 포함된 필드 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

엔터티 타입에 포함된 필드 (계속) JOB_DESCRIPTION 엔터티 타입 (사용자를 위한 서브그룹이 아닌 오직 구현만을 위한 엔터티 타입) Job_Number (외래 키) Line_Number (사용자에게 중요하지 않고 오직 구현만을 위한 것) Description_Line JOB_ASSIGNMENT 엔터티 타입 Effective_Date Salary Performance_Rating Employee_SSN (외래 키) LOCATION 엔터티 타입 Location_Name Address Interoffice_Code

ILF나 EIF의 계산 예: 복잡도 행렬 ILF와 EIF에 관한 복잡도 행렬

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

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

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

ILF나 EIF의 계산 예: 복잡도 ILF와 EIF에 관한 복잡도 행렬에 의해 3개의 low ILF, 한 개의 low EIF

ILF나 EIF의 계산 예: 미조정된 기능 점수
3개의 low ILF: 21, 한 개의 low EIF: 5

트랜잭션 기능의 유형 외부 입력 외부 출력 외부 조회
3 트랜잭션 기능의 크기 측정 트랜잭션 기능의 유형 외부 입력 외부 출력 외부 조회

트랜잭션 기능의 유형 트랜잭션 기능은 어플리케이션이 사용자에게 제공하는 기능을 나타냄
외부 입력(EI)은 어플리케이션 안으로 들어오는 데이터(ILF를 유지하기 위해) 혹은 제어 정보(시스템의 동작을 변경하기 위해)의 처리 외부 조회(EQ)는 ILF, EIF에서 데이터나 제어 정보의 검색을 통해 어플리케이션 밖으로 데이터를 내 보냄 외부 출력(EO)은 데이터나 제어 정보의 검색이 아닌 프로세싱 논리를 가지고 데이터를 어플리케이션 밖으로 데이터를 내 보냄

외부 입력 (EI) 정의: EI는 어플리케이션의 경계 밖에서 안으로 들어가는 데이터나 제어 정보를 처리하는 어플리케이션의 기본 프로세스이고, 처리된 데이터는 하나 이상의 ILF를 유지하고, 제어 정보는 ILF를 유지하지 않을 수도 있음 의미: 하나 이상의 ILF를 유지하고, 프로세싱 논리를 통해 어플리케이션의 동작을 변경하는 것

외부 입력 (계속) 정의 기본 프로세스는 사용자에게 의미 있는 가장 작업 단위로, 독립적(self-contained)이어야 하고 계산 중인 어플리케이션의 비즈니스를 일관된 상태로 두어야 함 예 1: 직원을 추가하는 어플리케이션에서 급여나 부양 가족과 같은 부분 정보를 추가하는 것은 사용자 관점의 기본 프로세스가 아니고, 일부 정보만을 추가하면 어플리케이션의 비즈니스가 비일관된 상태로 남게 됨 예 2: 세 개의 화면으로 구성되는 고용 보험 입력에서 기본 프로세스는 세 화면 모두를 완성하는 것을 요구면, 한 화면의 필드나 필드의 일부를 완성하는 것은 독립적인 프로세스가 아니고 비즈니스를 일관된 상태로 두지 않음

외부 입력 (계속) 정의 데이터는 어플리케이션에 의해 처리되는 사실(facts), 수(figures) 등의 모임
고용 보험에서 직원 이름, 수령인의 선택, 보험 요율 제어 정보는 어플리케이션의 기본 프로세스에 영향을 주기 위해 어플리케이션에 의해 이용되는 데이터 프로세스를 유지하거나 시작하기 위해 이용될 수 있음 예: 시스템을 디폴트 상태로 유지하기 위한 제어 데이터, 실시간 시스템에서 센서나 기구 혹은 다른 어플리케이션으로부터 발생하는 시그널

외부 입력 (계속) 정의 유지(maintain)한다는 것은 어플리케이션의 기본 프로세스 동안 데이터를 수정하는 능력을 의미
예: add, change, delete, populate, revise, update, assign, save as, create 트랜잭션은 기본 프로세스이고, 전체 프로세스를 구성하지 않는 변경, 삭제, 라인의 저장 등은 계산하지 않음 프로세싱 논리(processing logic)는 사용자가 기본 프로세스를 완성하기 위해 특별하게 요청하는 요구사항 대개 프로세싱 논리의 조합이 기본 프로세스를 완성하기 위해 요구됨 예: EI의 기본 프로세스가 다중 검증, 필터, 재정렬 등을 포함 프로세싱 논리 자체가 EI, EO, EQ의 유일성을 결정하지않음 재정렬이 트랜잭션의 유일성을 결정하지 않음

EI의 프로세싱 논리의 예 검증(validations) 수학식이나 계산 동등한 값으로의 변환
여러 데이터 값을 비교하기 위한 데이터의 필터링과 선택 적용 가능한 것을 결정하기 위한 조건 분석 ILF의 갱신 ILF나 EIF의 참조 데이터나 제어 정보의 검색 유도된 데이터의 생성 시스템 동작의 변경 경계 밖에서의 정보의 준비와 프리젠테이션 어플리케이션 경계 안으로 들어가는 데이터나 제어 정보를 받는 기능 데이터 집합의 재정렬이나 재배열

IFPUG의 EI 데이터 계산 규칙 데이터는 어플리케이션 경계 밖으로부터 수신되어야 한다.
어플리케이션의 기본 프로세스를 통해 ILF에 있는 최소한 하나의 데이터가 유지되어야 한다. 프로세스는 사용자에게 의미 있는 가장 작업 작업 단위이어야 한다. 프로세스는 독립적이어야 하고 기능 점수를 계산하는 어플리케이션의 비즈니스를 일관된 상태로 두어야 한다. 식별된 프로세스에 대해 다음 규칙 중 하나가 적용되어야 한다. 프로세싱 논리는 유일하거나 다른 외부 입력에 의해 수행되는 프로세싱 논리와 상이해야 한다. 데이터 요소의 집합은 다른 외부 입력에 관해 식별된 집합과 상이해야 한다. 참조되는 ILF나 EIF는 다른 외부 입력에 의해 참조되는 것들과 상이해야 한다.

IFPUG의 EI 트랜잭션 계산 규칙 제어 정보는 어플리케이션 경계 밖으로부터 수신되어야 한다.
제어 정보는 어플리케이션의 요구사항을 준수하는지를 보장하기 위해 사용자에 의해 명세화되어야 한다. 프로세스는 사용자에게 의미 있는 가장 작업 작업 단위이어야 한다. 프로세스는 독립적이어야 하고 기능 점수를 계산하는 어플리케이션의 비즈니스를 일관된 상태로 두어야 한다. 식별된 프로세스에 대해 다음 규칙 중 하나가 적용되어야 한다. 프로세싱 논리는 유일하거나 다른 외부 입력에 의해 수행되는 프로세싱 논리와 상이해야 한다. 데이터 요소의 집합은 다른 외부 입력에 관해 식별된 집합과 상이해야 한다. 참조되는 ILF나 EIF는 다른 외부 입력에 의해 참조되는 것들과 상이해야 한다.

EI의 추가적인 예 ILF를 유지하는데 이용되는 트랜잭션 데이터 제어 정보를 제공하는 입력
sale, lost item, scheduled appointment, transfer, new hire, insurance form 제어 정보를 제공하는 입력 예: 지진 탐지기가 지구의 움직임을 기록 처리를 요청하는 다른 어플리케이션에서 온 메시지 다른 어플리케이션으로부터의 트랜잭션 파일 현금 판매와 신용 카드 거래와 같이 별도의 처리를 요구하는 상이한 유형의 다중 트랜잭션 포함 ILF를 유지하는 입력 제어를 시작하거나 데이터를 입력하는 사용자 기능 이전 어플리케이션에서 유지되었으나 개발 프로젝트나 확장 프로젝트의 일부로 새로 개발되는 ILF로 데이터가 이전될 때 컨버전 노력을 통해 처리되어야 하는 데이터 파일 어플리케이션 기능 점수가 아닌 프로젝트 기능 점수 계산의 일부로 포함됨 처리를 시작하게 하는 물리적인 데이터 HELP, 메시지 파일, parameter 등을 포함하는 임의의 ILF의 유지보수

EI로 잘못 식별되는 예 어플리케이션 내에서 ILF를 유지하는데 이용되지 않고 다른 어플리케이션에 의해 읽히는 참조 데이터는 전형적인 EIF 조회나 출력의 입력 요구 측면 네비게이션이나 선택을 위해 이용되지만 ILF를 유지하지 않는 메뉴 화면 어플리케이션의 사용자 로그 온 화면 동일한 논리를 호출하는 여러 방법 여러 화면에서 동일한 기능이나 트랜잭션을 수행하는 두 개의 액션 키는 하나로 계산되어야 함 필드를 채우거나 데이터를 이동하기 위해 화면 상에서 데이터의 포인팅과 클릭킹

EI로 잘못 식별되는 예 (계속) 스크린 데이터의 다시 보기(refreshing) 혹은 취소
삭제나 임의의 다른 트랜잭션에 대해 사용자에게 확인 요청하는 메시지에 대한 응답 동일한 어플리케이션 내에서 온라인 처리와 일괄 처리 사이에 전달된 데이터 어플리케이션 경계를 넘지 않음 동일한 어플리케이션 내에서 클라이언트와 서버 사이에 전달된 데이터

EI의 복잡도 EI의 개수와 각각의 기능 복잡도가 함께 미조정된 기능 점수의 계산에 영향을 미친다. 식별된 각각의 EI는 관련된 데이터 요소 타입(DET)과 참조 파일 타입(FTR)의 수를 기준으로 기능 복잡도가 결정된다. 기능 복잡도(functional complexity)는 DET와 FTR의 개수에 따라 low, average, high 중 하나의 등급을 부여함 (복잡도 행렬에 정의) 데이터 요소 타입(DET)은 사용자가 인식 가능한, 유일하고, 반복되지 않는 필드나 속성으로 외래 키 속성을 포함 참조 파일 타입(FTR)은 간단하게 참조 파일이라고 부르며, EI 트랜잭션에 의해 유지되거나 읽히는 ILF와 EI 트랜잭션에 의해 읽히는 EIF의 총 개수

IFPUG의 DET 계산 규칙 EI의 기본 프로세스를 완성하기 위해 어플리케이션의 경계를 지나는 외래 키를 포함하여 사용자가 유일하게 식별 가능한 반복되지 않는 필드 각각에 대해 하나의 DET로 계산한다. 예: item number, quantity sold, date는 데이터가 어떻게 물리적으로 저장되었는지 관계 없이 각각이 sale 트랜잭션 상의 하나의 DET로 계산됨 사용자에 의해 입력되지는 않으나 (경계를 넘지 않은), EI를 통해 어플리케이션에 의해 검색되거나 유도되어 ILF에서 유지되는 필드에 대해서는 DET로 계산하지 않는다. 예: 시스템이 생성한 날짜, 검색된 값, 구좌 번호, 계산된 값

IFPUG의 DET 계산 규칙 (계속) 주소 라인처럼 물리적으로는 여러 필드로 저장되었으나, 단일 정보로 사용자가 요구하는 논리적 필드는 하나의 DET로 계산한다. 처리 동안 에러가 발생했음을 나타내거나, 처리가 완료되었음을 확인하거나, 처리가 계속되어야 함을 증명하기 위해 어플리케이션의 경계 밖으로 시스템 응답 메시지를 전송하는 기능에 대해 하나의 DET로 계산한다. 여러 메시지가 존재함에도 불구하고 메시지 전체를 하나의 DET로 계산 동일한 논리를 호출하는 여러 방법이 존재하더라 EI의 액션을 명세하는 기능에 대해 하나의 DET로 계산한다. EI의 동일한 액션에 대한 명령어나 기능 키를 함께 하나의 DET로 계산

IFPUG의 FTR 계산 규칙 EI의 기본 프로세스에 의해 유지되는 각 ILF에 대해서 하나의 FTR로 계산한다.
EI의 처리 동안 읽히는 내부 논리 파일(ILF)이나 외부 인터페이스 파일(EIF) 각각에 대해서 하나의 FTR로 계산한다. EI에 의해 유지되고 읽히는 각 ILF에 대해서 오직 하나의 FTR로 계산한다.

EI의 계산 예: 요구사항 직원 정보를 유지, 조회, 기록하는 기능이 필요. 생성된 리포트는 다른 어플리케이션에 의해 유지되는 파일에서 얻은 직원에 대한 위치 데이터를 포함. 업무 정보를 유지, 조회, 기록하는 기능이 필요. 업무 기술(Job Description)은 80 문자 단위의 라인들로 구성되고, 이 정보는 업무(Job)와 독립적으로 유지되지 않음. 직원에 대한 업무 배정(Job Assignment)을 유지, 조회, 기록하는 기능이 필요. 회사 내의 특정 위치에 있는 직원의 리스트를 포함한 위치 데이터(Location Data)에서 위치를 조회하고 기록하는 기능이 필요. 이 위치 데이터는 읽을 수만 있고 다른 어플리케이션에 의해서 유지됨.

EI의 계산 예: 프로세스 모델 EMPLOYEE-MAINTENANCE CREATE-EMPLOYEE

ILF와 EIF의 계산 결과 EMPLOYEE 엔터티 타입: ILF, 서브 그룹이 존재하므로 별도의 RET 계산 않음

ILF와 EIF의 계산 결과 JOB_DESCRIPTION 엔터티 타입: 구현상의 이유로만 존재하는 JOB의 일부

ILF와 EIF의 복잡도 계산 결과 ILF와 EIF에 관한 복잡도 행렬에 의해 3개의 low ILF, 한 개의 low EIF

EI의 계산 예: 복잡도 행렬

EI의 계산 예: DET에 관한 가정 각 입력 트랜잭션이 에러 메시지 (에러 메시지에 대해 하나의 DET로 계산)를 리턴하고, 최소한 하나의 명령 키(각 EI에 대해 다른 DET로 계산)를 가짐. 생성 기능과 갱신 기능은 특정 ILF의 모든 필드를 액세스 하지만, 삭제 기능은 기본 키만을 액세스. 배정(assign) 기능과 전보(transfer) 기능은 Performance_Rating 필드를 액세스 하지 않으며, 평가(evaluate) 기능은 Salary 필드를 액세스 하지 않음. 각 트랜잭션에 대해 에러 메시지와 명령 키인 추가적인 두 개의 DET를 계산.

EI의 계산 예: FTR에 관한 가정 유지되는 ILF와 편집 목적으로 참조해야 하는 다른 ILF 혹은 EIF를 계산해야 함.
Employee를 생성할 때 EMPLOYEE와 LOCATION이라는 두 개의 FTR을 가짐. Employee를 삭제할 때 EMPLOYEE를 유지하고 JOB_ASSIGNMENT를 참조하거나 갱신.

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)

EI의 계산 예: 복잡도 행렬 6개의 low EI, 두 개의 average EI(create update), 두 개의 high EI(assign, transfer)

EI의 계산 예: 미조정된 기능 점수 6개의 low EI, 두 개의 average EI(create update), 두 개의 high EI(assign, transfer) 미조정된 기능 점수는 38

외부 출력 (EO) 정의: EO는 어플리케이션의 경계 밖으로 나가는 데이터나 제어 정보를 생성하는 어플리케이션의 기본 프로세스이다. 그 의미는 데이터나 제어 정보의 검색이 아닌 프로세싱 논리(processing logic)를 통해 사용자에게 정보를 제시하는 것이다. 프로세싱 논리는 최소한 하나의 수학식이나 계산을 포함해야 하고, 유도된 데이터를 생성하고, 하나 이상의 ILF를 유지하고, 혹은 시스템의 동작(behavior)을 변경하는 것이다.

외부 출력 (계속) 정의 기본 프로세스는 사용자에게 의미 있는 가장 작업 단위로, 독립적(self-contained)이어야 하고 계산 중인 어플리케이션의 비즈니스를 일관된 상태로 두어야 함 예 : 여러 페이지로 구성된 리포트는 하나의 EO로만 계산됨 데이터는 출력 트랜잭션에 의해 처리되는 사실(facts), 수(figures) 등의 모임 예: 위의 리포트 트랜잭션에 포함된 데이터 필드(department name, department number, address, month, total monthly sales, total monthly purchases, current running total for the year)

외부 출력 (계속) 정의 제어 정보는 어플리케이션의 기본 프로세스에 영향을 주기 위해 어플리케이션에 의해 이용되는 데이터
어플리케이션에 의해 사용자나 다른 어플리케이션에게 송신됨 예: 사용자가 명세한 기능 요구사항을 준수하는지 보증하기 위해 송신되는 데이터로, 특정 내부 조건이 설정되었음을 알리는 메시지 포함 가능 예: 실시간 시스템에서의 alarm, 메시지, 생산 라인의 중단 통보와 같은 outgoing 시그널 유도된 데이터는 추가적인 데이터를 생성하기 위해 기본 데이터의 변환을 통해 생성 하나 이상의 ILF, EIF로부터 정보의 직접적인 검색, 컨버전, 편집이 아닌 프로세싱을 요구

외부 출력 (계속) 정의 유지는 기본 프로세스를 통해 데이터를 수정하는 능력
payroll check를 생성하는 동안 ILF에 수표 번호를 자동적으로 입력 프로세싱 논리(processing logic)는 기본 프로세스를 완성하기 위해 사용자에 의해 특별하게 요청되는 요구사항 대개 프로세싱 논리의 조합이 기본 프로세스를 완성하기 위해 요구됨 예: EO의 기본 프로세스가 다중 검증, 필터, 재정렬 등을 포함 프로세싱 논리 자체가 EI, EO, EQ의 유일성을 결정하지 않음 재배열, 재포맷팅, 재정렬이 유일한 프로세싱 논리가 아님

EO의 프로세싱 논리의 예 검증(validations) 수학식이나 계산 동등한 값으로의 변환
여러 데이터 값을 비교하기 위한 데이터의 필터링과 선택 적용 가능한 것을 결정하기 위한 조건 분석 ILF의 갱신 ILF나 EIF의 참조 데이터나 제어 정보의 검색 유도된 데이터의 생성 시스템 동작의 변경 경계 밖에서의 정보의 준비와 프리젠테이션 어플리케이션 경계 안으로 들어가는 데이터나 제어 정보를 받는 기능 데이터 집합의 재정렬이나 재배열

IFPUG의 EO 계산 규칙 데이터나 제어 정보는 어플리케이션 경계 밖으로 송신되어야 한다.
1. 최소한 하나의 수학식이나 계산을 포함 2. 유도된 데이터의 생성 3. 최소한 하나의 ILF의 유지 4. 어플리케이션의 동작을 변경 프로세스는 사용자에게 의미 있는 가장 작업 작업 단위이어야 한다. 프로세스는 독립적이어야 하고 기능 점수를 계산하는 어플리케이션의 비즈니스를 일관된 상태로 두어야 한다.

IFPUG의 EO 계산 규칙 (계속) 식별된 프로세스에 대해 다음 규칙 중 하나가 적용되어야 한다.
프로세싱 논리는 유일하거나 다른 외부 출력에 의해 수행되는 프로세싱 논리와 상이해야 한다. 데이터 요소의 집합은 다른 외부 출력에 관해 식별된 집합과 상이해야 한다. 동일한 필드에서 상이한 데이터를 가지는 개개인에 관해서 생성된 account statement는 하나의 EO 상세한 수준과 개략적인 수준에서 각각 별도로 생성된 두 리포트는 유일한 프로세싱 논리와 계산을 가지므로 두 개의 EO로 계산됨 참조되는 ILF나 EIF는 다른 외부 입력에 의해 참조되는 것들과 상이해야 한다.

EO의 추가적인 예 알고리즘이나 계산이 필요한 리포트
데이터가 갱신되거나 유도될 때 혹은 기본 프로세스의 일부로 갱신될 때 다른 어플리케이션으로 송신되는 데이터, 파일, 메시지 생성시에 check number와 check report를 동시에 갱신하는 check 개발 프로젝트나 확장 프로젝트의 부분으로서 데이터가 이전될 때 컨버전 노력의 합계를 기록하는 컨버전 리포트 어플리케이션 기능 점수가 아닌 프로젝트 기능 점수 계산의 일부로 포함됨 화면 상에 표시되거나 파일에 전달되는 유도된 정보 혹은 계산된 정보 계산을 필요로 하는 막대 그래프와 파이 챠트 전화로 전달되는 계산된 응답 사용자에게 전달되거나 무기시스템에서 다른 어플리케이션으로 전달되는 무기 발사 정보 현재까지의 사용액이 계산된 신용카드 분실 기록 제안된 보험 요율의 계산

EO로 잘못 식별되는 예 부서별 리포트와 같이 상이한 데이터 값을 가지는 동일한 리포트
데이터를 보내는 어플리케이션 내에서 식, 계산, 유도된 데이터를 가지지 않고 ILF를 유지하지 않는 리포트 대부분 EQ 상세한 리포트에 포함된 요약 필드 상세 리포트는 EO 데이터를 보내는 어플리케이션 내에서 식, 계산, 유도된 데이터를 가지지 않고 ILF를 유지하지 않는 다른 어플리케이션으로 보내지는 파일 프로세싱 논리가 동일한 다중 미디어 스크린 데이터의 다시 보기나 취소 다른 프로세싱 논리가 없는 데이터 집합의 재정렬이나 재배열 다른 어플리케이션에 의해 읽히지만, 기능 점수가 계산되는 어플리케이션에 저장된 참조 데이터 계산되는 어플리케이션에 의해 EO로 처리되지 않음

EO로 잘못 식별되는 예 (계속) 조회나 출력의 입력 요구 측면 HELP 시스템 로그 오프
대부분 EQ로 계산 시스템 로그 오프 동일한 출력 프로세스를 호출하는 여러 방법 EI의 편집이나 검증 혹은 EO나 EQ의 요구 측면의 결과로 나오는 에러 메시지 데이터가 처리 되었음을 확인하는 확인 메시지 둘 이상의 어플리케이션으로 보내지는 동일한 데이터 SQL이나 FOCUS와 같은 언어의 사용을 통해 사용자가 지시하고 제어하는 특별한 리포트 어플리케이션 경계를 넘지 않고 동일한 어플리케이션 내에서 온라인과 일괄 처리 사이에 전달된 데이터 어플리케이션 경계를 넘지 않고 동일한 어플리케이션 내에서 클라이언트와 서버 사이에 전달된 데이터

EO의 복잡도 EO의 개수와 각각의 기능 복잡도가 함께 미조정된 기능 점수의 계산에 영향을 미친다. 식별된 각각의 EO는 관련된 데이터 요소 타입(DET)과 참조 파일 타입(FTR)의 수를 기준으로 기능 복잡도가 결정된다. 기능 복잡도(functional complexity)는 DET와 FTR의 개수에 따라 low, average, high 중 하나의 등급을 부여함 (복잡도 행렬) 데이터 요소 타입(DET)은 대개 어플리케이션의 경계를 넘고 사용자가 인식 가능한, 유일하고, 반복되지 않는 필드나 속성 참조 파일 타입(FTR)은 간단하게 참조 파일이라고 부르며, EO 트랜잭션에 의해 유지되거나 읽히는 ILF와 EO 트랜잭션에 의해 읽히는 EIF의 총 개수

IFPUG의 DET 계산 규칙 어플리케이션의 경계를 들어가고, 무슨 데이터가 언제 어떻게 기본 프로세스에 의해 검색, 생성되는가를 명세하는데 필요하고 사용자가 유일하게 식별 가능한 반복되지 않는 필드 각각에 대해 하나의 DET로 계산한다. 종종 제어 정보, 선택 정보, 프로세싱 매개변수로 고려 어플리케이션의 경계를 나가고, 사용자가 유일하게 식별 가능한 반복되지 않는 필드 각각에 대해 하나의 DET로 계산한다. 외래 키 속성과 제어 정보 만일 하나의 DET가 경계를 모두 들어오고 나가면, 기본 프로세스에 대해 단지 하나로만 계산

IFPUG의 DET 계산 규칙 (계속) 처리 동안 에러가 발생했음을 나타내거나, 처리가 완료되었음을 확인하거나, 처리가 계속되어야 함을 증명하기 위해 어플리케이션의 경계 밖으로 시스템 응답 메시지를 전송하는 기능에 대해 하나의 DET로 계산한다. 여러 메시지가 존재하더라도 메시지 전체를 하나의 DET로 계산 동일한 논리 프로세스를 호출하는 여러 방법이나 다중 키가 존재하더라도 EO의 액션을 명세하는 기능에 대해 하나의 DET로 계산한다. OK 버튼, 기능 키, 액션 키, 마우스 클릭 페이지 번호, 위치 정보(행과 열), 페이지 명령(이전, 다음), 날짜/시간 필드를 포함하는 페이지 변수나 시스템이 생성하는 스탬프는 계산하지 않는다. DET는 검색된 날짜를 포함하나 리포트 인쇄 날짜와 같은 시스템 생성 날짜는 포함하지 않음

IFPUG의 DET 계산 규칙 (계속) 리포트 제목, 스크린 ID, 열 표제(column heading), 필드 제목을 포함하는 리터럴은 계산하지 않는다. 물리적으로는 여러 필드로 저장되었지만 사용자에 의해 단일 정보로 요구되는 논리적 필드에 대해서는 하나의 DET로 계산한다. 세 개의 필드로 저장되나 하나의 정보로 사용되는 날짜나 이름은 각각 하나의DET로 계산됨 그래픽 디스플레이에서 각 유형의 레이블과 동등한 각 수치에 대해 각각 하나의 DET로 계산한다. 예: 파이 챠트는 두 개의 DET (범주, 백분율) 단일 단어, 문장, 단락, 여러 단락으로 구성될 수 있는 텍스트 정보에 관해 하나의 DET로 계산한다.

IFPUG의 FTR 계산 규칙 EO의 처리 동안 읽히는 내부 논리 파일(ILF)이나 외부 인터페이스 파일(EIF) 각각에 대해서 하나의 FTR로 계산한다. EO의 기본 프로세스에 의해 유지되는 각 ILF에 대해서 하나의 FTR로 계산한다. EO에 의해 유지되고 읽히는 각 ILF에 대해서 오직 하나의 FTR로 계산한다.

EO의 계산 예: 요구사항 직원 정보를 유지, 조회, 기록하는 기능이 필요. 생성된 리포트는 다른 어플리케이션에 의해 유지되는 파일에서 얻은 직원에 대한 위치 데이터를 포함. 업무 정보를 유지, 조회, 기록하는 기능이 필요. 업무 기술(Job Description)은 80 문자 단위의 라인들로 구성되고, 이 정보는 업무(Job)와 독립적으로 유지되지 않음 직원에 대한 업무 배정(Job Assignment)을 유지, 조회, 기록하는 기능이 필요. 회사 내의 특정 위치에 있는 직원의 리스트를 포함한 위치 데이터(Location Data)에서 위치를 조회하고 기록하는 기능이 필요. 이 위치 데이터는 읽을 수만 있고 다른 어플리케이션에 의해서 유지됨.

EI의 계산 예: 프로세스 모델 EMPLOYEE-MAINTENANCE CREATE-EMPLOYEE

EO의 계산 예: 복잡도 행렬

EO의 계산 예: DET과 FTR에 관한 가정 각 리포트가 유도된 데이터나 계산된 데이터를 가지고 있는 모든 조회는 EO로 계산됨. JOB REPORT를 제외한 각 리포트가 경계를 지나는 6개에서 19개 사이의 DET를 가짐. Employee report는 EMPLOYEE 파일과 LOCATION 파일을 참조 두 파일 간의 관계(relationship) 존재.

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로 가정

EO의 계산 예: 복잡도 행렬 3개의 average EO(EMPLOYEE, JOB-ASSIGNMENT, LOCATION)와 한 개의 low EO(JOB)

EO의 계산 예: 미조정된 기능 점수 3개의 average EO와 한 개의 low EO 미조정된 기능 점수는 19

외부 조회 (EQ) 정의: EQ는 어플리케이션의 경계 밖으로 데이터나 제어 정보의 검색 결과를 내는 어플리케이션의 기본 프로세스이다. 그 의미는 ILF나 EIF로부터 데이터나 제어 정보의 검색을 통해 사용자에게 정보를 제시하는 것이다. 프로세싱 논리(processing logic)는 수학식이나 계산을 포함하지 않고, 유도된 데이터를 생성하지 않는다. 프로세싱 동안 ILF가 유지되지 않고, 어플리케이션의 동작(behavior)이 변경되지 않는다.

외부 조회 (계속) 정의 기본 프로세스는 사용자에게 의미 있는 가장 작업 단위로, 독립적(self-contained)이어야 하고 계산 중인 어플리케이션의 비즈니스를 일관된 상태로 두어야 함 예 : 검색을 위해 5개의 필드를 입력해야 하는 경우, 필드 중 하나 혹은 일부를 입력하는 것은 기본 프로세스가 아님. 완전한 트랜잭션이 되기 위해서는 정보의 요청, ILF나 EIF로부터 추출, 정보의 전달을 포함 데이터는 조회 트랜잭션에 의해 처리되는 정보의 필드 제어 정보는 어플리케이션의 기본 프로세스에 영향을 주는 데이터 어떤 데이터가 언제 어떻게 처리되는지 명세 그 자체가 기본 프로세스는 아님

외부 조회 (계속) 정의 프로세싱 논리(processing logic)는 기본 프로세스를 완성하기 위해 사용자에 의해 특별하게 요청되는 요구사항 대개 프로세싱 논리의 조합이 기본 프로세스를 완성하기 위해 요구됨 예: EQ의 기본 프로세스가 다중 검증, 필터, 재정렬 등을 포함 프로세싱 논리 자체가 EI, EO, EQ의 유일성을 결정하지 않음 재배열, 재포맷팅, 재정렬이 유일한 프로세싱 논리가 아님 유도된 데이터는 추가적인 데이터를 생성하기 위해 기본 데이터의 변환을 통해 생성 하나 이상의 ILF, EIF로부터 정보의 직접적인 검색, 컨버전, 편집이 아닌 프로세싱을 요구 EQ는 유도된 데이터를 포함하지 않음 유지는 기본 프로세스를 통해 데이터를 수정하는 능력 EQ는 데이터를 유지하지 않음. EI나 EO가 데이터를 유지함

IFPUG의 EQ 계산 규칙 데이터나 제어 정보는 어플리케이션 경계 밖으로 송신되어야 한다.
데이터나 제어 정보는 하나 이상의 ILF나 EIF로부터 검색되어야 한다. 기본 프로세스의 프로세싱 논리는 유도된 데이터를 생성하지 않아야 한다. 기본 프로세스의 프로세싱 논리는 수학식이나 계산을 포함하지 않아야 한다. 프로세스는 ILF를 유지하지 않아야 한다. 프로세스는 사용자에게 의미 있는 가장 작업 작업 단위이어야 한다. 프로세스는 독립적이어야 하고 기능 점수를 계산하는 어플리케이션의 비즈니스를 일관된 상태로 두어야 한다.

IFPUG의 EQ 계산 규칙 (계속) 식별된 프로세스에 대해 다음 규칙 중 하나가 적용되어야 한다.
프로세싱 논리는 유일하거나 어플리케이션 내에서 다른 외부 조회에 의해 수행되는 프로세싱 논리와 상이해야 한다. 데이터 요소의 집합은 어플리케이션의 다른 외부 조회에 관해 식별된 집합과 상이하다. 참조되는 ILF나 EIF는 어플리케이션의 다른 외부 조회에 의해 참조되는 것들과 상이하다.

EQ의 예 하나 이상의 ILF, EIF로부터 검색되고 디스플레이되는 트랜잭션 데이터
View, lookup, display, browse, print와 같은 사용자 기능 동일한 프로세싱 논리를 가진 print와 view는 하나의 EQ로 계산됨 독립적인(stand-alone) 프로세스로 사용될 수 있고 이전에 계산된 EQ의 중복이 아닌 (변경이나 삭제 기능 이전의 데이터 검색에) 함축된 조회 식, 계산, 유도된 데이터를 포함하지 않으며 ILF를 유지하지 않고 주기적으로 생성되는 리포트 계산되지 않고 유지되는 시스템 데이터, 매개변수, 설정치(set up)의 리턴 어플리케이션에 특정된 보안을 제공하는 로그 온 화면 각 수준의 HELP ILF나 EIF의 필드나 스크린 검색 전자식 데이터 인터페이스나 톤(tone) 방식의 전화를 통해 유지되는 데이터 검색 식, 계산, 유도된 데이터를 포함하지 않고 ILF를 유지하지 않는 다른 어플리케이션으로 송신되는 파일 메일 박스의 메일 검색 ILF나 EIF에서 유지되는 데이터를 리턴하기 위한 화면상의 리스트 박스 혹은 데이터의 포인팅과 클릭킹

EQ로 잘못 식별되는 예 동일한 논리를 호출하는 여러 방법 프로세싱 논리가 동일한 다중 미디어
여러 화면에서 동일한 기능이나 트랜잭션을 수행하는 두 개의 액션 키는 오직 한 번만 계산 프로세싱 논리가 동일한 다중 미디어 어플리케이션의 여러 영역이나 화면에서 접근할 수 있는 조회 한 번만 계산 네비게이션이나 선택을 위해 사용되지만, 유지되는 데이터를 검색하지 않는 메뉴 화면 사용자가 어플리케이션에 들어갈 수 있게 하지만, 보안 조치가 없는 로그 온 화면 유도되거나 계산된 데이터의 검색 EO로 계산됨 상이한 프로세싱 논리를 가지지 않는 데이터 집합의 재정렬이나 재배열 데이터를 확인하도록 사용자에게 요청하는 메시지에 대한 응답

EQ로 잘못 식별되는 예 (계속) 오류, 확인 메시지 온 라인 시스템 문서
동일한 어플리케이션 내의 온 라인과 일괄 처리 사이에 전달된 데이터 어플리케이션 경계를 넘지 않음 동일한 어플리케이션 내에서 클라이언트와 서버 사이에 전달된 데이터 시스템 로그 오프 유지되는 데이터에서 검색되지 않은 데이터 예: hard-coded 데이터는 계산하지 않음

EQ의 복잡도 EQ의 개수와 각각의 기능 복잡도가 함께 미조정된 기능 점수의 계산에 영향을 미친다. 식별된 각각의 EQ는 관련된 데이터 요소 타입(DET)과 참조 파일 타입(FTR)의 수를 기준으로 기능 복잡도가 결정된다. 기능 복잡도(functional complexity)는 DET와 FTR의 개수에 따라 low, average, high 중 하나의 등급을 부여함 (복잡도 행렬) 데이터 요소 타입(DET)은 어플리케이션의 경계를 넘고 사용자가 인식 가능한, 유일하고, 반복되지 않는 필드나 속성 참조 파일 타입(FTR)은 간단하게 참조 파일이라고 부르며, EQ 트랜잭션에 의해 유지되거나 읽히는 ILF와 EQ 트랜잭션에 의해 읽히는 EIF의 총 개수

IFPUG의 DET 계산 규칙 어플리케이션의 경계를 들어가고, 무슨 데이터가 언제 어떻게 기본 프로세스에 의해 검색, 생성되는가를 명세하는데 필요하고 사용자가 유일하게 식별 가능한 반복되지 않는 필드 각각에 대해 하나의 DET로 계산한다. 종종 제어 정보, 선택 정보, 프로세싱 매개변수로 고려 어플리케이션의 경계를 나가고, 사용자가 유일하게 식별 가능한 반복되지 않는 필드 각각에 대해 하나의 DET로 계산한다. 외래 키 속성과 제어 정보가 포함됨 만일 하나의 DET가 경계를 모두 들어오고 나가면, 기본 프로세스에 대해 단지 하나로만 계산

IFPUG의 DET 계산 규칙 (계속) 처리 동안 에러가 발생했음을 나타내거나, 처리가 완료되었음을 확인하거나, 처리가 계속되어야 함을 증명하기 위해 어플리케이션의 경계 밖으로 시스템 응답 메시지를 전송하는 기능에 대해 하나의 DET로 계산한다. 여러 메시지가 존재함에도 불구하고 메시지 전체를 하나의 DET로 계산 동일한 논리 프로세스를 호출하는 여러 방법이나 다중 키가 존재하더라도 EQ의 액션을 명세하는 기능에 대해 하나의 DET로 계산한다. OK 버튼, 기능 키, 액션 키, 마우스 클릭 페이지 번호, 위치 정보(행과 열), 페이지 명령(이전, 다음), 날짜/시간 필드를 포함하는 페이지 변수나 시스템이 생성하는 스탬프는 계산하지 않는다. DET는 검색된 날짜를 포함하나 리포트 인쇄 날짜와 같은 시스템 생성 날짜는 포함하지 않음

IFPUG의 DET 계산 규칙 (계속) 리포트 제목, 스크린 ID, 열 표제(column heading), 필드 제목을 포함하는 리터럴은 계산하지 않는다. 물리적으로는 다중 필드로 저장되었지만 사용자에 의해 단일 정보로 요구되는 논리적 필드에 대해서는 하나의 DET로 계산한다. 세 개의 필드로 저장되나 하나의 정보로 사용되는 날짜나 이름은 각각 하나의DET로 계산됨 그래픽 디스플레이에서 각 유형의 레이블과 동등한 각 수치에 대해 각각 하나의 DET로 계산한다. 저장된 데이터로 퍼센트 값을 읽는 것처럼 계산 없이 그래프가 생성되면, 그래프는 EQ가 될 수 있음 단일 단어, 문장, 단락, 여러 단락으로 구성될 수 있는 텍스트 정보에 관해 하나의 DET로 계산한다.

IFPUG의 FTR 계산 규칙 EQ의 처리 동안 읽히는 내부 논리 파일(ILF)이나 외부 인터페이스 파일(EIF) 각각에 대해서 하나의 FTR로 계산한다.

EQ의 계산 예: 요구사항 직원 정보를 유지, 조회, 기록하는 기능이 필요. 생성된 리포트는 다른 어플리케이션에 의해 유지되는 파일에서 얻은 직원에 대한 위치 데이터를 포함. 업무 정보를 유지, 조회, 기록하는 기능이 필요. 업무 기술(Job Description)은 80 문자 단위의 라인들로 구성되고, 이 정보는 업무(Job)와 독립적으로 유지되지 않음 직원에 대한 업무 배정(Job Assignment)을 유지, 조회, 기록하는 기능이 필요. 회사 내의 특정 위치에 있는 직원의 리스트를 포함한 위치 데이터(Location Data)에서 위치를 조회하고 기록하는 기능이 필요. 이 위치 데이터는 읽을 수만 있고 다른 어플리케이션에 의해서 유지됨.

EQ의 계산 예: 프로세스 모델 EMPLOYEE-MAINTENANCE CREATE-EMPLOYEE

EQ의 계산 예: 복잡도 행렬

EQ의 계산 예: DET, FTR에 관한 가정 EO와 마찬가지로 EQ도 데이터 검색을 위해 어플리케이션의 경계를 들어가는 필드와 제어 정보를 가질 수 있음 각 제어 정보가 디스플레이됨을 가정 오류, 증명, 확인 메시지에 대해 하나의 DET로 계산 최소한 하나의 명령 키(command key)를 가짐 참조 파일은 하나만 존재 검증을 위해 다른 파일을 참조할 필요가 없고, 기본 파일을 제외한 파일에서 검색되는 필드가 없음

EQ의 계산 예: DET와 FTR EMPLOYEE-INQUIRY: FTR 1, DET 10
JOB-INQUIRY: FTR 1, DET 6 JOB-ASSIGNMENT-INQUIRY: FTR 1, DET 7 LOCATOIN-INQUIRY: FTR 1, DET 5

EQ의 계산 예: 복잡도 행렬 4개의 low EQ

EQ의 계산 예: 미조정된 기능 점수 4개의 low EQ 미조정된 기능 점수는 12

개요 기능 점수 계산 과정 일반 시스템 특성 값 조정 인자
4 일반 시스템 특성 개요 기능 점수 계산 과정 일반 시스템 특성 값 조정 인자

개요 정보 시스템이 제공하는 기능에는 데이터 기능과 트랜잭션 기능에 의해 충분히 표현되지 않는 일반적인 요인들이 있고, FPA에 이를 반영하는 일반 시스템 특성(General System Characteristics: GSC)이 있음 값 조정 인자(Value Adjustment Factor: VAF)는 조정된 기능 점수(adjusted function point) 계산을 위한 승수(multiplier)로 사용됨 일반 시스템 특성(GSC)을 모두 무시하고 미조정된 기능 점수로 최종적인 기능 점수를 대치하려는 일부 경향이 있음 ISO는 기능 점수 측정을 위해 일반 시스템 특성(GSC)을 배제하려는 작업을 진행 중임

개요: 일반 시스템 특성(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

개요: 일반 시스템 특성 (계속) 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) FP = UFP  VAF

일반 시스템 특성 (GSC) 각 GSC의 영향의 정도(DI)가 IFPUG의 지침에 따라 평가되어 0 에서 5 사이의 값을 가져야 한다. 0 존재하지 않거나 영향이 없음(Not present, or no influence) 1 우연한 영향(Incidental influence) 2 온건한 영향(Moderate influence) 3 평균적인 영향(Average influence) 4 중대한 영향(Significant influence) 5 시종 강한 영향(Strong influence throughout)

GSC: 1. Data communications
어플리케이션이 프로세서와 직접적으로 통신하는 정도를 나타낸다. 0 순수한 일괄 처리 혹은 stand-alone PC 1 일괄 처리이지만 원격 데이터 입력 혹은 원격 출력 2 일괄 처리이지만 원격 데이터 입력과 원격 출력 3 온 라인 데이터 수집 또는 일괄 처리나 질의 시스템에 대한 원격 처리(TP) front end를 포함 4 front end 이상의 것이지만, 오직 한 가지 유형의 TP 통신 프로토콜을 지원 5 front end 이상의 것이고, 어플리케이션이 한 가지 유형 이상의 TP 통신 프로토콜을 지원

GSC: 1. Data communications (계속)
David’s notes 순수한 일괄 처리 어플리케이션만이 0. 일괄 처리와 stand-alone PC를 포함한 대부분의 어플리케이션은 원격 데이터 입력 기능 뿐만 아니라 원격 프린팅 기능을 가진다. front-end 데이터 입력 기능을 가졌지만, 일괄 처리를 통해 내부의 논리 파일을 갱신하는 어플리케이션은 3. 만일 갱신이 대화식으로 일어나면 4. 여러 유형의 원격 통신 프로토콜이 존재하면 5. 전형적인 일괄 처리 어플리케이션은 0에서 3, 온 라인 어플리케이션은 3에서 4, 실시간, 원격 통신, 혹은 프로세스 제어 시스템은 4 혹은 5.

GSC: 2. Distributed data processing
어플리케이션의 컴포넌트 사이에 데이터를 전송(transfer)하는 정도를 나타낸다. 분산 데이터 처리 기능은 어플리케이션 경계 내의 특성이다. 0 시스템의 컴포넌트 사이에 데이터나 프로세싱 기능의 전송을 돕지 않음 1 PC 스프레드 시트나 PC DBMS와 같은 다른 시스템의 컴포넌트 상에서 사용자 프로세싱을 위한 데이터를 준비 2 데이터는 전송을 위해 준비되고 나서, 시스템의 다른 컴포넌트(사용자 프로세싱을 위한 것이 아닌) 상으로 전송되고 처리됨 3 분산 처리와 데이터 전송이 온 라인이고 단지 한 방향으로만 이루어짐 4 분산 처리와 데이터 전송은 온 라인이고 양방향 모두로 이루어짐 5 프로세싱 기능은 시스템의 가장 적절한 컴포넌트에서 동적으로 수행됨

GSC: 2. Distributed data processing (계속)
David’s notes 분산 어플리케이션이나 실시간 어플리케이션은 이 범주내의 값이 지정되어야 한다. 대부분의 어플리케이션은 0, 기본적인(primitive) 분산 어플리케이션은 1이나 2, 클라이언트나 웹 어플리케이션은 2에서 4, 실시간, 원격 통신, 혹은 프로세스 제어 시스템은 0에서 5. 5의 값을 갖기 위해서는 다중 서버나 프로세서가 존재해야 하고, 각각은 실시간 가용성을 기초로 동적으로 선택된다.

GSC: 3. Performance 어플리케이션 개발에 영향을 주는 응답 시간(response time)과 처리율(throughput)의 performance를 고려하는 정도를 나타낸다. 0 사용자에 의한 특별한 성능 요구가 없음 1 성능과 설계 요구가 언급되고 검토되지만, 특별한 액션이 요구되지 않음 2 응답 시간이나 처리율이 peak hours동안 중요함. CPU 활용에 대한 특별한 설계가 요구되지 않음. 프로세싱 데드라인은 그 다음 날 3 응답 시간이나 처리율이 모든 시간 동안 중요함. CPU 활용에 대한 특별한 설계가 요구되지 않음. 인터페이싱 시스템을 가진 프로세싱 데드라인 요구사항이 강하게 제기됨 4 추가적으로, 언급된 사용자 성능 요구사항은 설계 단계에서 성능 분석 작업이 필요할 정도로 매우 엄격함 5 추가적으로, 언급된 사용자 성능 요구를 만족하기 위해 설계, 개발, 구현 단계에서 성능 분석 도구가 사용됨

GSC: 3. Performance (계속) David’s notes
transaction rate(GSC 5)와 그 성격이 매우 유사하다. 둘 모두가 설계, 개발, 설치 단계에서 성능을 고려한다. 응답 시간은 전형적으로 대화식 프로세싱과 관련되고, 처리율은 일괄 처리와 관련된다. 설계 단계 동안 성능 분석 작업을 요구하면 4, 성능 분석 도구의 이용을 요구하면 5. 전형적으로 일괄 처리 어플리케이션은 0에서 4, 온 라인 어플리케이션은 0에서 4. 그리고 실시간, 원격 통신, 프로세스 제어 시스템은 0에서 5.

GSC: 4. Heavily used configuration
어플리케이션의 개발에 영향을 주는 컴퓨터 자원의 제한 정도를 나타낸다. 0 명시적이거나 암시적인 운영상의 제한이 포함되지 않음 1 운영상의 제한이 존재하지만, 전형적인 어플리케이션보다 덜 제한적임. 제한을 만족하기 위한 특별한 노력이 필요하지 않음 2 어떤 보안 고려 사항이나 타이밍 고려 사항이 포함됨 3 어플리케이션의 특정 부분에 대해 특정 프로세서 요구사항이 포함됨 4 언급된 운영상의 제한이 중앙 처리기나 전용 처리기에 특별한 제한을 요구함 5 추가적으로, 시스템의 분산 컴포넌트에 특별한 제한이 존재함

GSC: 4. Heavily used configuration (계속)
David’s notes 대부분의 어플리케이션이 2의 값을 가짐. 어플리케이션이 클라이언트-서버, 실시간, 원격 통신, 프로세스 제어 시스템이면 3에서 5. 동일한 트랜잭션을 처리하고 가장 신속한 처리 수단을 탐색하는 전용 처리기나 다중 처리기가 필요할 수 있다.

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는 설계 단계에서 성능 분석을 요구하기에 충분할 정도로 높고, 추가적으로 설계, 개발, 설치 단계에서 성능 분석 도구의 이용을 요구함

GSC: 5. Transaction rate (계속)
David’s notes Performance(GSC 3)와 그 성격이 매우 비슷하다. 둘 모두가 설계, 개발, 설치 단계에서 성능을 고려한다. 설계 단계 동안 성능 분석 작업을 요구하면 4, 성능 분석 도구의 이용을 요구하면 5. 전형적으로 일괄 처리 어플리케이션은 0에서 3. 온 라인 어플리케이션은 0에서 4. 실시간, 원격 통신, 프로세스 제어 시스템은 0에서 5.

GSC: 6. Online data entry 데이터가 대화식(interactive) 트랜잭션을 통해 입력되는 정도를 나타낸다. 0 모든 트랜잭션이 일괄 처리 모드에서 처리 1 트랜잭션의 1에서 7 퍼센트가 대화식 데이터 입력 2 트랜잭션의 8에서 15 퍼센트가 대화식 데이터 입력 3 트랜잭션의 16에서 23 퍼센트가 대화식 데이터 입력 4 트랜잭션의 24에서 30 퍼센트가 대화식 데이터 입력 5 트랜잭션의 30 퍼센트 이상이 대화식 데이터 입력

GSC: 6. Online data entry (계속)
David’s notes EI, EO, EQ 트랜잭션 각각은 기본 프로세스이다. GSC에 관한 큰 문제 중의 하나는 IFPUG의 지침이 수년간 갱신되지 않았다는 것이다. 그 결과로 인해 이 값들은 실제적이지 않다. 그럼에도 불구하고 industry data는 이 지침들을 이용해 계산되어 왔다. 전형적으로 일괄 처리 어플리케이션은 0에서 1, 그리고 온 라인, 실시간, 원격 통신, 프로세스 제어 시스템이 5의 값을 가진다.

GSC: 7. End user efficiency
Human factors와 사용의 용이성을 나타낸다. Navigational aids(예: 기능 키, 점프, 동적으로 생성된 메뉴) 메뉴 온 라인 HELP와 문서 자동화된 커서 이동 스크롤링 원격 프린팅(온 라인 트랜잭션을 경유) 미리지정된 기능 키 온 라인 트랜잭션으로부터 제출된 일괄 처리 작업 스크린 데이터의 커서 선택 역상 비디오, 강조, 색, 밑줄, 다른 표시 기호의 사용 온 라인 트랜잭션의 하드 카피 사용자 문서화 마우스 인터페이스 팝업 윈도우 비즈니스 기능을 달성하기 위해 가능한 한 적은 스크린 이중 언어 지원(네 개의 항목으로 계산됨) 다중 언어 지원(여섯 개의 항목으로 계산됨)

GSC: 7. End user efficiency (계속)
앞에서 기술된 항목의 포함 여부를 기준으로 0 어느 것도 포함되지 않음 1 하나부터 세 개까지 포함 2 네 개부터 다섯 개까지 포함 3 여섯 개 이상 포함되나, 효율성에 관련된 특정한 사용자 요구사항이 존재하지 않음 4 여섯 개 이상 포함되고, 최종 사용자 효율성에 관해 언급된 요구사항은 human factors를 위한 설계 작업을 포함되도록 요구함 (예를 들어, key stroke의 최소화, 디폴트의 최대화, 템플릿의 이용) 5 여섯 개 이상 포함되고, 최종 사용자 효율성에 관해 언급된 요구사항은 목적이 달성되었다는 것을 예시하기 위한 특별한 도구와 프로세스의 이용을 요구함

GSC: 7. End user efficiency (계속)
David’s notes 순수한 일괄 처리 어플리케이션은 0. front-end 데이터 입력 화면을 가지지만, 내장된 템플릿이나 디폴트를 가지지 않는 대부분의 어플리케이션은 3. 만일 디폴트, 템플릿, 중요한 네비게이션 도구가 존재하면 4. 기능성보다는 어플리케이션의 유용성을 시험할 사용자 실험실이 존재하면 5. 실시간, 원격 통신, 프로세스 제어 시스템은 이 GSC에 해당되지 않음.

GSC: 8. Online update 내부 논리 파일이 온 라인으로 갱신되는 정도를 나타낸다. 0 온 라인 갱신이 없음
0 온 라인 갱신이 없음 1 하나에서 세 개의 제어 파일의 온 라인 갱신이 포함됨. 갱신되는 양이 적고 복구가 쉬움 2 네 개 이상의 제어 파일의 온 라인 갱신이 포함됨. 갱신되는 양이 적고 복구가 쉬움 3 주요 내부 논리 파일의 온 라인 갱신이 포함됨 4 추가적으로, 데이터 손실을 막기 위한 보호가 필수적이고 시스템에서 특별하게 설계되고 프로그램됨 5 추가적으로, 많은 양의 갱신이 복구 과정에서 비용을 고려하게 함. 운영자의 간섭을 최소화한 고도로 자동화된 복구 절차가 포함됨

GSC: 8. Online update (계속)
David’s notes 내부 논리 파일을 대화식으로 갱신하는 일괄 처리 어플리케이션은 0에서 2. 내부 논리 파일을 갱신하는 대부분의 온 라인 어플리케이션은 3 이상. 만일 시스템 안에 데이터의 손실을 보호하는 기능이 프로그램되면(단지 백업을 통한 것이 아니라) 4. 어플리케이션 내에 내장된 고도로 자동화된 복구 기능이 존재하면 5. 실시간, 원격 통신, 프로세스 제어 시스템은 대개 4 혹은 5.

GSC: 9. Complex processing
프로세싱 논리가 어플리케이션의 개발에 영향을 미친 정도를 나타낸다. 컴포넌트의 종류 1. 민감한 제어(sensitive control), 특정한 보안 처리 2. 광범위한(extensive) 논리적인 처리 3. 광범위한(extensive) 수학적인 처리 4. 다시 처리되어야 하는 불완전한 트랜잭션으로 귀결되는 많은 예외 처리(예: TP 인터럽션에 기인한 불완전한 ATM 트랜잭션, 데이터 값의 손실, 실패한 검증) 5. 다중 입출력 가능성을 다루기 위한 복잡한 처리 (예: 멀티미디어, 기기 독립적인 입출력)

GSC: 9. Complex processing (계속)
앞에서 기술된 컴포넌트의 포함 여부를 기준으로 0 아무 것도 포함되지 않음 1 하나가 포함됨 2 두 가지가 포함됨 3 세 가지가 포함됨 4 네 가지가 포함됨 5 다섯 가지 모두가 포함됨

GSC: 9. Complex processing (계속)
David’s notes 이 GSC 지침은 다섯 가지의 별도의 개별적인 특성을 가진다. 1. 어플리케이션이 특정 개인에게 다른 사람은 할 수 없는 데이터를 보거나 입력하도록 보안을 제공하는가? 2. 논리적인 (if/then/else) 프로세싱이 광범위하게 존재하는가? 3. 수학적인 프로세싱이 광범위하게 (덧셈과 뺄셈과 같은 단순한 수학 이상의) 존재하는가? 4. 복잡한 편집이나 검증(validations)이 존재하는가? 5. 어플리케이션에 다중 미디어(예, 음성 입력과 스크린 입력)가 포함되는가?

GSC: 10. Reusability 다른 어플리케이션에서 이용 가능하도록 어플리케이션과 어플리케이션 내의 코드가 특별하게 설계, 개발, 지원되는 정도를 나타낸다. 0 재사용 가능한 코드가 없음 1 재사용 가능한 코드가 어플리케이션 내에서 사용됨 2 어플리케이션의 10 퍼센트 미만이 한 명 이상의 사용자 요구(needs)를 고려함 3 어플리케이션의 10 퍼센트 이상이 한 명 이상의 사용자 요구(needs)를 고려함 4 어플리케이션이 재사용을 용이하게 하기 위해 특별히 패키지되거나 문서화됨, 그리고 어플리케이션이 소스 코드 수준에서 사용자에 의해 재사용을 위해 수정 가능 5 어플리케이션이 재사용을 용이하게 하기 위해 특별히 패키지되거나 문서화됨, 그리고 어플리케이션이 유지보수에 의해 수정 가능

GSC: 10. Reusability (계속) David’s notes
재사용 코드를 사용하는 사람에게는 1의 값을 할당한다. 표준화된 재사용 가능한 소프트웨어는 신뢰도와 일관성이 향상되어 사용자를 위한 기능이 증가된다. 그 기능을 기초로 2에서 5 사이의 값이 할당되고, 다른 어플리케이션에서 활용되기를 기대하여 개발, 문서화, 코드의 시험에 추가 노력을 투입한다.

GSC: 11. Installation ease
어플리케이션의 개발에 이전의 환경의 컨버전이 영향을 주는 정도를 나타낸다. 0 사용자에 의해 언급된 특별한 고려사항이 없고, 설치를 위해 요구되는 특별한 설정(set up)이 없음 1 사용자에 의해 언급된 특별한 고려사항이 없지만, 설치를 위해 특별한 설정이 요구됨. 2 사용자에 의해 컨버전과 설치 요구 사항이 언급되고, 컨버전과 설치 지침이 제공되고 시험됨. 프로젝트에 대한 컨버전의 영향은 중요하게 고려되지 않음 3 사용자에 의해 컨버전과 설치 요구 사항이 언급되고, 컨버전과 설치 지침이 제공되고 시험됨. 프로젝트에 대한 컨버전의 영향은 중요하게 고려됨 4 위의 2에 추가하여, 자동화된 컨버전과 설치 도구가 제공되고 시험됨 5 위의 3에 추가하여, 자동화된 컨버전과 설치 도구가 제공되고 시험됨

GSC: 11. Installation ease (계속)
David’s notes 종종 개발자들은 이전에 존재했던 데이터를 새로운 데이터 파일로 변환하고, 파일이 실제의 데이터를 가지게 하고, 이식을 위한 설치 소프트웨어를 개발하기 위한 많은 노력을 투입할 것을 요구 받는다. 일정이 개선되고 일관성이 증가되면 사용자에게 제공되는 기능이 향상된다. 컨버전과 설치 요구 사항의 어려움과 쉬움, 중요성에 따라 점수를 부여한다.

GSC: 12. Operational ease 시동, 백업, 복구 절차와 같은 운영 측면에 주의하는 정도를 나타낸다.
시동, 백업, 복구 절차와 같은 운영 측면에 주의하는 정도를 나타낸다. 0 정상적인 백업 절차를 제외하고 사용자에 의해 언급된 특별한 운영상의 고려 사항이 없음 1-4 어플리케이션에 적용할 다음의 항목을 선택한다. 각 항목은 특별하게 언급된 것을 제외하고는 1의 값을 가진다. 효과적인 시동, 백업, 복구 절차가 제공되지만, 운영자의 간섭이 요구됨 효과적인 시동, 백업, 복구 절차가 제공되지만, 운영자의 간섭이 요구되지 않음(두 항목으로 계산됨) 테이프 마운트의 필요가 최소화됨 페이퍼 핸들링 필요가 최소화됨 5 어플리케이션이 무인 운영을 위해 설계됨. 무인 운영은 어플리케이션의 시동과 셧 다운을 제외하고 시스템을 운영하기 위해 운영자 간섭이 요구되지 않음을 의미한다. 자동적인 오류 복구가 어플리케이션의 특성이다.

GSC: 12. Operational ease (계속)
David’s notes 레거시 시스템이 아닌 한, 테이프 마운트와 페이퍼(천공 카드, 천공 페이퍼 테이프)가 없으면 각각 1의 값을 부여한다. 만일 시동, 백업, 복구를 위해 운영자 간섭이 요구되면 3의 값을 부여한다. 만일 운영자 간섭이 요구되지 않으면 4의 값을 부여하고, 어플리케이션이 스스로 운영되고 오류로부터 자동적으로 복구되면 5의 값을 부여한다. 대개 온 라인 어플리케이션에 대해서는 3의 값을 부여하고, 운영자에 의해 직접 방해 받지 않고 운영되는 플랜트-프로세싱, 원격 통신, 실시간 시스템을 위해 더 높은 값을 부여한다.

GSC: 13. Multiple sites 여러 장소의 사용자 조직을 위해 개발되는 정도를 나타낸다 .
0 한 명 이상의 사용자나 사이트의 필요(needs)를 고려하도록 요구되지 않음 1 여러 사이트의 필요성이 설계에서 고려되었고, 어플리케이션은 오직 동일한 하드웨어와 소프트웨어 환경 아래에서만 운영되도록 설계됨 2 여러 사이트의 필요성이 설계에서 고려되었고, 어플리케이션은 오직 유사한 하드웨어와 소프트웨어 환경 아래에서만 운영되도록 설계됨 3 여러 사이트의 필요성이 설계에서 고려되었고, 어플리케이션은 오직 상이한 하드웨어와 소프트웨어 환경 아래에서만 운영되도록 설계됨 4 여러 사이트에서 어플리케이션을 지원하도록 문서화 계획과 지원 계획이 제공되고 시험됨, 그리고 어플리케이션은 위의 1이나 2로 기술됨 5 여러 사이트에서 어플리케이션을 지원하도록 문서화 계획과 지원 계획이 제공되고 시험됨, 그리고 어플리케이션은 위의 3으로 기술됨

GSC: 13. Multiple sites (계속)
David’s notes 여러 사이트에서 운영될 소프트웨어, 하드웨어를 포함하는 어플리케이션을 인도하는데 필요한 노력과 사용자 기능을 고려한다. 터미널이나 PC와 같은 입력 장치를 반영한다. 소프트웨어, 하드웨어가 동일, 유사(윈도우 95, NT), 상이한가(윈도우, Mac, Unix)? 문서가 제공되고 시험 계획을 지원하는가?

GSC: 14. Facilitate change
변경을 쉽도록 하기 위해 어플리케이션이 특별하게 설계, 개발, 지원되는 정도를 나타낸다. 0 변경을 최소화하거나 촉진하도록 어플리케이션을 설계하는 특별한 사용자 요구 사항이 없음 1-5 어플리케이션에 적용할 다음의 항목을 선택한다. 융통성 있는 질의와 리포트 기능이 제공되고 simple 복잡도의 조회를 다룰 수 있음 - 예를 들어, 오직 하나의 내부 논리 파일에 적용되는 and/or 논리(한 항목으로 계산됨) 융통성 있는 질의와 리포트 기능이 제공되고 average 복잡도의 조회를 다룰 수 있음 - 예를 들어, 하나 이상의 내부 논리 파일에 적용되는 and/or 논리(두 항목으로 계산됨) 융통성 있는 질의와 리포트 기능이 제공되고 complex 복잡도의 조회를 다룰 수 있음 - 예를 들어, 하나 이상의 내부 논리 파일에 적용되는 and/or 논리의 조합 (세 항목으로 계산됨) 비즈니스 제어 데이터가 온 라인 대화식 프로세스를 가진 사용자에 의해 유지되는 테이블에 보관되지만, 변경은 단지 그 다음 날에만 효과가 있음(한 항목으로 계산됨) 비즈니스 제어 데이터가 온 라인 대화식 프로세스를 가진 사용자에 의해 유지되는 테이블에 보관되지만, 변경은 즉시 효과가 있음(두 항목으로 계산됨)

GSC: 14. Facilitate change (계속)
David’s notes 융통성 있는 질의와 리포트 기능이 제공된다. 제어 데이터는 사용자에 의해 유지 가능한 테이블에서 그룹화된다. 첫 번째 영역은 SQL이나 FOCUS와 같은 언어 혹은 더욱 동적인 리포트 생성 도구(예, Crystal Reports)에 의해 제공되는 질의, 리포트 작성 기능을 다룬다. 이러한 특성에는 0에서 3의 값을 할당한다. 두 번째 영역과 마지막 두 항목은 데이터, 제어 정보가 어플리케이션 내에서 혹은 어플리케이션에 의해 유지되는 상호작용(interactivity)에 관련된다. 대화형, 실시간, 원격 통신, 프로세스 제어 시스템은 전형적으로 마지막 두 값을 할당한다.

값 조정 인자 (VAF) 14개의 일반 시스템 특성(GSC)이 값 조정 인자(VAF)로 합산된다. VAF는 조정된 기능 점수 계산을 결정하기 위해 미조정된 기능 점수 계산을 ±35 퍼센트 범위에서 조정한다. 일반적으로, 간단한 일괄 처리 어플리케이션은 15 미만, front-end 일괄 처리 어플리케이션은 15에서 30 사이, 실시간, 원격 통신, 프로세스 제어 시스템은 30에서 60 사이의 TDI를 가진다. 다음 절차에 의해 VAF를 계산한다. 1. 각 GSC에 관한 영향의 정도(DI)를 결정하기 위해 0에서 5사이의 값으로 14개의 GSC를 평가한다. 2. 전체 영향의 정도(TDI)를 구하기 위해 14개의 GSC의 DI를 더한다. 3. 다음 식으로 VAF를 계산한다. VAF = (TDI × 0.01)

개요 조정된 기능 점수 계산 예: Catalog 비즈니스 기능 점수 계산 공식
5 기능 점수의 계산과 응용 개요 조정된 기능 점수 계산 예: Catalog 비즈니스 기능 점수 계산 공식

개요 기능 점수를 계산하는 방법을 빠르고 쉽게 설명하기 위해 catalog 비즈니스의 예를 검토
데이터 기능과 트랜잭션 기능의 식별 규칙을 값 조정 인자(VAF)와 함께 사용하여 조정된 기능 점수(adjusted function point)를 계산 데이터 기능과 트랜잭션 기능은 각각의 복잡도 행렬에 기초하여 미조정된 기능 점수 가중치를 가짐 일반 시스템 특성(GSC)은 각각 독립적으로 계산되어 0과 5 사이의 유일한 값이 할당되고, 이 값들이 더해져 TDI가 계산됨 TDI를 이용하여 VAF를 계산하고, VAF는 미조정된 기능 점수에 곱해져 조정된 기능점수를 구함

조정된 기능 점수 계산 1. 기능 점수의 유형 결정 2. 기능 점수 계산 범위와 어플리케이션 경계를 식별

예: Catalog 비즈니스 Business Catalog Sales: add, change, delete
Descriptions Inventory Sales Vendor Address File Descriptions: add, change, delete retrieve Inventory: End-of-Month Report Sales: add, change, delete

예: 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개

예: 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)

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.

예: 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

예: Catalog 비즈니스 – VAF와 FP
VAF = (TDI × 0.01) = 0.96 FP (Adjusted Function Point) = UFP × VAF = 75

예: 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 Average High Total 3 × × × × × × × × × 3 × × × 1 × × × Total unadjusted Function Points (UFP) = 78

예: Catalog 비즈니스 – worksheet (계속)
General System Characteristics Degree of Characteristic Influence 1. Data communications 2. Distributed data processing 3. Performance 4. Heavily used configuration 5. Transaction rate 6. Online data entry 7. End user efficiency Degree of Characteristic Influence 8. Online update 9. Complex processing 10. Reusability 11. Installation ease 12. Operational ease 13. Multiple sites 14. Facilitate change Total degree of influence (TDI) = 31 VAF Value adjustment factor = (TDI × 0.01) = 0.96 FP Adjusted function point count = UFP × VAF = 75

기능 점수 계산 공식: 개발 프로젝트 개발 프로젝트 기능 점수
개발 프로젝트 기능 점수 계산은 세 가지 기능의 컴포넌트로 구성된다. 1. EI, EO, EQ로 구성되는 어플리케이션의 미조정된 기능 점수 계산 2. 이전 데이터를 새로운 ILF로 변환하는 컨버전 기능 (이 컴포넌트는 종종 이전 데이터 파일의 입력으로 구성된다 [EI로 계산되거나 이미 계산된 새로운 ILF로의 입력 데이터] 그리고 컨버전 리포트에 관한 EO도 가능) 3. 어플리케이션 값 조정 인자 (VAF)

기능 점수 계산 공식: 개발 프로젝트 (계속) 개발 프로젝트 기능 점수 DFP는 개발 프로젝트 기능 점수
개발 프로젝트 기능 점수 계산 공식 DFP = (UFP + CFP) × VAF DFP는 개발 프로젝트 기능 점수 UFP는 미조정된 기능 점수 CFP는 데이터의 컨버전에 의해 포함되는 기능 점수. VAF는 값 조정 인자

기능 점수 계산 공식: 확장 프로젝트 확장 프로젝트 기능 점수
1. EI, EO, EQ, ILF, EIF로 구성되는 어플리케이션의 미조정된 기능 점수 확장 프로젝트에 의한 추가(이전에 존재하지 않았던 기능 – 예: 새로운 EQ, EI, ILF, EO) 확장 프로젝트에 의한 변경(이전에 존재했으나 현재 상이한 필드, FTR을 가지는 기능, 상이한 프로세싱을 요구하는 기능) 확장 프로젝트에 의한 삭제(어플리케이션에서 삭제 – 예:삭제된 리포트) 2. 이전의 데이터를 새로운 ILF로 변환하는 컨버전 기능(종종 예전의 데이터 파일의 입력으로 구성된다[EI로 계산되거나 새로운 ILF의 입력 데이터] 그리고 컨버전 리포트에 관한 EO도 가능) 3. 두 개의 값 조정 인자(VAF는 변경될 수 있음, 이 경우에 이전의 VAF와 새로운 VAF가 존재할 수 있음)

기능 점수 계산 공식: 확장 프로젝트 (계속) 확장 프로젝트 기능 점수 계산 공식
EFP = [(ADD + CHGA + CFP) × VAFA] + (DEL × VAFB) EFP는 확장 프로젝트 기능 점수 ADD는 확장 프로젝트에 의해 추가된 기능들의 미조정된 기능 점수 CHGA는 확장 프로젝트에 의해 수정된 기능들의 미조정된 기능 점수(이 컴포넌트는 단지 수정에 의해 추가된 필드가 아닌, 수정이 이루어진 후의 기능의 값을 반영한다. 전형적인 에러는 변경된 DET와 FTR, 혹은 RET만을 계산하는 것이다. 그러나 변경된 것뿐만 아니라 기존 기능의 시험에 포함된 노력을 고려해야 한다) CFP는 데이터의 컨버전에 의해 포함된 기능 점수 VAFA는 확장 프로젝트 이후의 어플리케이션의 값 조정 인자 DEL은 확장 프로젝트에 의해 삭제된 기능의 미조정된 기능 점수 VAFB는 확장 프로젝트 이전의 어플리케이션의 값 조정 인자

기능 점수 계산 공식: 어플리케이션 어플리케이션 기능 점수
컨버전은 개발 프로젝트의 부분이므로 설치된 어플리케이션의 기능 점수 계산에 포함되지 않음 어플리케이션 기능 점수는 다음 컴포넌트로 구성됨 1. EI, EO, EQ, ILF, EIF로 구성되는 어플리케이션의 미조정된 기능 점수 2. 어플리케이션 값 조정 인자 (VAF)

기능 점수 계산 공식: 어플리케이션 (계속) 어플리케이션 기능 점수 계산 시점 1. 어플리케이션이 초기에 인도될 때
2. 확장 프로젝트가 어플리케이션의 기능을 변경할 때 어플리케이션의 기능 점수가 증가되는 (새로운) 기능의 추가 어플리케이션의 기능 점수가 증가, 감소되거나 혹은 영향이 없는 기능의 변경 어플리케이션의 기능 점수가 감소되는 기능의 삭제 어플리케이션의 기능 점수가 증가, 감소되거나 혹은 영향이 없는 값 조정 인자의 변경

기능 점수 계산 공식: 어플리케이션 (계속) 초기의 어플리케이션 기능 점수 계산 초기의 어플리케이션 기능 점수 계산 공식
AFP = ADD × VAF AFP는 초기의 기능 점수 ADD는 개발 프로젝트에 의해 설치된 기능의 미조정된 기능 점수 VAF는 값 조정 인자

기능 점수 계산 공식: 어플리케이션 (계속) 확장 후의 어플리케이션 기능 점수 계산
확장 후의 어플리케이션 기능 점수 계산 공식 AFP = [(UFPB + ADD + CHGA) - (CHGB + DEL)] × VAFA AFP는 어플리케이션의 조정된 기능 점수 UFPB는 확장 프로젝트 이전의 어플리케이션 미조정된 기능 점수 ADD는 확장 프로젝트에 의해 추가된 기능의 미조정된 기능 점수 CHGA는 확장 프로젝트에 의해 변경된 기능의 미조정된 기능 점수(변경 후의 기능 점수 값을 반영) CHGB는 변경 이전에 확장에 의해 변경된 기능의 미조정된 기능 점수(확장 프로젝트 이전의 기능 점수 값을 반영) DEL은 확장 프로젝트에 의해 삭제된 기능의 미조정된 기능 점수 VAFA는 확장 프로젝트 이후 어플리케이션의 값 조정 인자

개요 기초적인 사례 연구 프로젝트 관리 사례 연구 초기 정의 단계에서 기능 점수 계산
6 사례 연구 개요 기초적인 사례 연구 프로젝트 관리 사례 연구 초기 정의 단계에서 기능 점수 계산

개요 기능 점수의 실제적인 계산 예 서로 연결되는 작은 두 개의 문제로 구성되는 기초적인 사례 연구
프로젝트 관리 시스템을 대상으로 하는 사례 연구 프로젝트 생명주기 초기의 기능 점수 계산 연습을 위한 사례 연구

기초적인 사례 연구: 문제 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차 키(두 번째 레코드 타입)로 사용될 것이다.

기초적인 사례 연구: 문제 A 문제 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에 관한 각 기능과 복잡도를 식별하라.

기초적인 사례 연구: 문제 A (계속)

기초적인 사례 연구: 문제 B Function Point Calculation Worksheet
문제 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 Average High Total × × × 6 × × × 7 × × × 15 × × × 10 Total unadjusted Function Points (UFP) =

General System Characteristics
기초적인 사례 연구: 문제 B (계속) General System Characteristics Degree of Characteristic Influence 1. Data communications 2. Distributed data processing 3. Performance 4. Heavily used configuration 5. Transaction rate 6. Online data entry 7. End user efficiency Degree of Characteristic Influence 8. Online update 9. Complex processing 10. Reusability 11. Installation ease 12. Operational ease 13. Multiple sites 14. Facilitate change Total degree of influence (TDI) = VAF Value adjustment factor = (TDI × 0.01) = FP Adjusted function point count = UFP × VAF =

프로젝트 관리 사례 연구: 트랜잭션 기능 기술(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를 가진다.

프로젝트 관리 사례 연구: 트랜잭션 기능 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, 사무실 위치, 다음 배정 가능한 날짜를 포함한다.

프로젝트 관리 사례 연구: 트랜잭션 기능 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의 서술을 담은 전자 우편이 배정된 사람에게 보내진다.

프로젝트 관리 사례 연구: 데이터 기능 데이터 기능: 모든 파일과 그들에 관련된 필드들과 기본 키(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)

프로젝트 관리 사례 연구: 데이터 기능(계속)
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 address 5. Help 파일 (외부에서 유지됨) Screen ID; PK Field ID; PK Help text (up to six lines possible)

프로젝트 관리 사례 연구: 데이터 기능(계속)
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 address Task coordinator's name Task coordinator's address 제공된 정보를 기초로 데이터 기능과 트랜잭션 기능의 복잡도를 식별하라.

초기 정의 단계에서 기능 점수 계산 직원과 방문객 모두를 위한 주차 공간 배정을 할당, 유지, 보고서를 생성하는 주차 공간 배정 어플리케이션 (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)

초기 정의 단계에서 기능 점수 계산(계속) 6. 근무 종료 시간(end of day)에 방문객 보고서를 Parking Assignment 파일과 Personnel 파일 모두로부터의 정보, 방문객 총 수와 함께 생성 7. 직원에게 영구 주차 공간을 배정, Personnel 파일로 검증 8. 직원의 영구 주차 공간을 전환, Personnel 파일로 검증 9. 직원에게 배정된 영구 주차 공간을 폐쇄 10. 영구 주차 공간 배정에 관한 주간 보고서를 Parking Assignment 파일과 Personnel 파일 모두로부터의 정보, 합계와 함께 생성 11. 유지보수를 위해 폐쇄된 주차 공간을 표시 12. 유지보수를 위해 폐쇄된 주차 공간을 조사(view) 13. 유지보수를 위해 폐쇄된 주차 공간을 다시 개방 14. 유지보수에 관한 주간 보고서를 전체 내용과 함께 생성

초기 정의 단계에서 기능 점수 계산(계속) 총 12개의 방문객 주차 공간과 144개의 직원용 영구 주차공간이 존재한다. 앞에서 언급한 것처럼, 데이터는 Building Personnel 어플리케이션에서 유지되는 Personnel 파일로부터 검색되고 참조되는 것으로 결정된다. 예상되는 데이터는 다음과 같다. 데이터 기능 Personnel 파일 First name (한 개의 필드로 고려) Middle name (한 개의 필드로 고려) Last name (한 개의 필드로 고려) Employee ID Office phone number Office location

초기 정의 단계에서 기능 점수 계산(계속) 데이터 기능과 트랜잭션 기능을 식별하고 복잡도를 추정하라.
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 데이터 기능과 트랜잭션 기능을 식별하고 복잡도를 추정하라.

참고문헌 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.

6-1 사례 연구의 답 문제 A 문제 B

사례 연구: 문제 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차 키(두번째 레코드 타입)로 사용된다.

사례 연구: 문제 A (계속) 문제 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에 관한 각 기능과 복잡도를 식별하라.

사례 연구: 문제 A (계속)

사례 연구: 문제 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차 키(두번째 레코드 타입)로 사용된다.

사례 연구: 문제 A (계속) 문제 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에 관한 각 기능과 복잡도를 식별하라.

사례 연구: 문제 A (계속)

기초적인 사례 연구: 문제 B Function Point Calculation Worksheet
문제 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 Average High Total 1 × × × × × × × × × 1 × × × 1 × × × Total unadjusted Function Points (UFP) = 35

General System Characteristics
기초적인 사례 연구: 문제 B (계속) General System Characteristics Degree of Characteristic Influence 1. Data communications 2. Distributed data processing 3. Performance 4. Heavily used configuration 5. Transaction rate 6. Online data entry 7. End user efficiency Degree of Characteristic Influence 8. Online update 9. Complex processing 10. Reusability 11. Installation ease 12. Operational ease 13. Multiple sites 14. Facilitate change Total degree of influence (TDI) = 26 VAF Value adjustment factor = (TDI × 0.01) = FP Adjusted function point count = UFP × VAF =

(Function Point Analysis)

Similar presentations

Presentation on theme: "(Function Point Analysis)"— Presentation transcript:

Similar presentations

About project

지원

로그인

Auth with social network:

(Function Point Analysis)

Similar presentations

Presentation on theme: "(Function Point Analysis)"— Presentation transcript:

Similar presentations

About project

지원