기능 점수 분석 (Function Point Analysis)

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

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


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

BuildingSecurity

LocationListing

PersonnelEmployee Data

LocationLocation Directory Data

updatedirectory

determine if employee

print monthly listing

request, retrieve, displayinformation from Location

and Personnel


기능 점수 계산 준비

예 : 각 직원의 근무 위치 정보를 유지하고 디스플레이하는 Location 어플리케이션

단계 1. 기능 점수 유형 개발 이력에 상관 없이 현재의 어플리케이션을 계산하므로 기능

점수의 유형은 어플리케이션 기능 점수

단계 2. 계산 범위와 어플리케이션 경계 범위 : 어플리케이션에 존재하는 모든 기능 경계 : Location, Location Listing, Clerk, Building Security, Personnel


기능 점수 계산 준비

단계 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 내에 유지되는 정보의 검색과 디스플레이


기능 점수 계산에 유용한 정보

개발의 초기 단계에서 활용할 수 있는 정보의 양은 적지만 , 개발이 진행됨에 따라 활용할 수 있는 정보의 양이 많아짐

유용한 정보를 얻을 수 있는 문서의 종류» 프로젝트 제안서» 고수준의 시스템 다이어그램» ER 다이어그램» 논리 데이터 모델» 데이터 흐름도» 객체 모델» 프로세스 모델» 요구 문서» 프로토타입» 기능 명세서» 유스 케이스


기능 점수 계산에 유용한 정보 ( 계속)

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


기능 점수의 유형 개발 프로젝트 기능 점수

» 처음 설치된 어플리케이션을 통해 사용자에게 제공되는 기능을 측정 » 초기의 어플리케이션 기능 점수로 계산되는 기능과 데이터 컨버전을 위해

필요한 기능 포함– Location 어플리케이션을 새로 개발되는 어플리케이션으로 대치하면 , 새로운

어플리케이션이 제공하는 기능 뿐만 아니라 예전 데이터 파일의 데이터를 새로운 데이터 파일로 변환하는 컨버전 기능을 함께 계산

» 원점에서 시작하는 계산이 아니라 이전에 인식된 기능을 검증하여 기능을 추가하는 연속적인 기능 점수 계산

» 프로젝트 개발 동안의 계산

Requirements

FunctionPointCount

FunctionPointCount

FunctionPointCount

FunctionPointCount

FunctionPointCount

InitialDesign

DetailedDesign Coding Testing Implementatio

nMaintenance


기능 점수의 유형 ( 계속 )

확장 프로젝트 기능 점수» 새로운 기능의 추가 , 예전 기능의 제거 , 기존 기능의 변경을

포함하여 기존 어플리케이션을 수정하여 사용자에게 제공되는 기능 어플리케이션 기능 점수

» 설치된 어플리케이션이 최종사용자에게 제공하는 현재의 기능» 현재 활용되고 유지되는 어플리케이션의 기능 점수» 기준선 (baseline) 에 해당


계산 범위와 어플리케이션의 경계

기능 점수의 계산 범위는 목적에 의해 결정» 크기를 측정하기 원하는 범위» 크기를 측정할 시스템 , 어플리케이션 , 어플리케이션의

부분 집합» 상용 패키지의 구입 , 아웃소싱 어플리케이션 , 특정 목적의

어플리케이션의 기능 포함

어플리케이션의 경계는 측정되는 어플리케이션과 외부 어플리케이션 혹은 사용자 영역 사이의 경계» 측정되는 어플리케이션과 다른 독립적인 어플리케이션 혹은

사용자 영역을 구분


기능 점수 계산을 위한 구성 요소

External User

ExternalInput

ExternalInquiry

ExternalOutput

InternalLogical File

ExternalInterface File

External Input

External Output

Application Boundary Other Applications


어플리케이션 경계를 식별하는 규칙

어플리케이션 경계는 사용자 뷰 (user’s view) 에 기반을 둠» 사용자의 언어로 어플리케이션의 범위와 비즈니스 기능을 정의

관련된 어플리케이션 사이의 경계는 기술적 요소보다는 비즈니스 측면의 기능에 기초함» MS Office 는 Word, Excel, PowerPoint, Access 로 구성되고 ,

각각은 별도의 MS Office 내의 어플리케이션 확장 중인 어플리케이션에 대한 초기의 어플리케이션 경계는

확장과 함께 변경됨» 추가된 기능은 경계를 확장시키고 삭제된 기능은 경계를 축소시킴» 변경된 기능은 어플리케이션의 기능 점수의 크기를 변경시킬 수

있음» 개발 프로젝트와 확장 프로젝트는 단일 어플리케이션 이상을

포함하고 , 다중 어플리케이션의 경계는 계산 범위 내에 포함되지만 별도로 계산


Accounting System 의 어플리케이션 경계

AccountingSystem

AccountsReceivable

GeneralLedger

AccountsPayable


Production System 의 어플리케이션 경계

ProductionSystem

ShopPlanner

MaterialInventory

WorkSchedule


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)» 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) 에 해당– 예 : 주소 테이블은 고객 파일 , 거래 파일 , 재고품 위치 파일 ,

직원 파일과 같은 논리적 그룹에 해당



정의» 데이터는 어플리케이션 내에서 유지되는 사실 (facts), 수

(figures) 등의 모임– check number, amount, date, payee, memo entry, account

number 는 checking account record 내에 유지됨

» 제어 정보는 어플리케이션의 기본 프로세스에 영향을 주기 위해 어플리케이션에 의해 이용되는 데이터

– 어떤 데이터가 언제 어떻게 처리되는지를 규정– 예 : Printer Manager 내에 유지되는 제어 데이터 ,

부정확하거나 부적절한 데이터를 거부하기 위한 편집 데이터 , 이벤트의 순서와 타이밍을 설정하는 날짜와 시간 , 이벤트를 제어하기 위한 threshold



정의» 유지 (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) 에 해당– 예 : 주소 테이블은 고객 파일 , 거래 파일 , 재고품 위치 파일 ,

직원 파일과 같은 논리적 그룹에 속함



정의» 데이터는 또 다른 어플리케이션 내에서 유지되는 사실

(facts), 수 (figures) 등의 모임– check number, amount, date, payee, memo entry, account

number 는 checking account record 내에 유지됨


– 어떤 데이터가 언제 어떻게 처리되는지를 규정– 예 : Printer Manager 내에 유지되는 제어 데이터는 PowerPoint

에 의해 읽힘 , 부정확하거나 부적절한 데이터를 거부하기 위한 편집 데이터의 참조 , 이벤트의 순서와 타이밍을 설정하는 날짜와 시간이 읽히거나 참조 , 이벤트를 제어하기 위한 threshold 의 설정



정의» 유지 (maintain) 된다는 것은 어플리케이션의 기본 프로세스

동안 데이터가 수정된다는 사실을 의미

» 기본 프로세스는 사용자에게 의미 있는 가장 작은 작업 단위– 창고에서 물건의 스크린 디스플레이는 다양한 서브 프로세스로

분할 될 수 있으나 , 물건의 양을 판단하기 위해 하나의 파일이 읽히고 별도의 파일은 물건의 내역을 참조하기 위해 읽힘

– 창고에서 물건을 출하 (issue) 하는 것은 기본 프로세스– 동일 트랜잭션으로 여러 EIF 갱신 가능


IFPUG 의 EIF 계산 규칙

데이터나 제어 정보의 그룹은 논리적이고 사용자가 식별 가능 데이터 그룹은 계산 중인 어플리케이션에 의해 참조되지만 ,

외부에 있음 데이터 그룹은 계산 중인 어플리케이션에 의해 유지되지 않음 데이터 그룹은 또 다른 어플리케이션에 의해 유지됨

» 데이터 그룹이 어플리케이션 내에서 일단 EIF 로 식별되고 나면 , 비록 다른 트랜잭션에 의해 참조 목적으로 이용된다고 해도 , 동일한 어플리케이션 내에서 또 다시 EIF 로 계산될 수 없음


EIF 의 공통적인 예

다른 어플리케이션에서 추출되고 읽히는 데이터 어플리케이션 외부에서 유지되는 보안 (security) 데이터 혹은

패스워드 데이터 어플리케이션 외부에서 유지되는 HELP 데이터 어플리케이션 외부에서 유지되는 Edit 데이터 어플리케이션 외부에서 유지되는 Parameter 데이터 어플리케이션 외부에서 유지되는 에러 파일과 에러 기술

(description)


EIF 로 잘못 식별되는 예

하나 이상의 ILF 를 유지하는 또 다른 어플리케이션에서 계산 중인 어플리케이션 내부로 수신된 데이터» 트랜잭션 데이터로 간주되어 EI 로 계산되어야 함

계산 중인 어플리케이션에 의해 유지되지만 , 상이한 어플리케이션에 의해 접근되고 이용되는 데이터» 상이한 어플리케이션에 대한 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 로 계산한다 .» 헤더 , 트레일러 , 별도의 텍스트 파일과 같이 활용되는 기술이나

방법론 때문에 존재하는 임의의 RET 는 계산하지 않음» 종종 둘 이상의 서브 그룹이 동일한 논리 파일 (ILF 혹은 EIF) 에

속함» 이러한 RET 들은 데이터의 저장과 논리 파일간의 관계를 생성하기

위해 이용되는 2 차 키의 존재로 식별 가능» 논리 파일의 데이터는 전형적으로 제 3 정규형의 데이터

만일 서브 그룹이 존재하지 않으면 , ILF 나 EIF 를 하나의 RET로 계산한다 .


ILF 나 EIF 의 계산 예 : 요구사항

직원 정보를 유지 , 조회 , 기록하는 기능이 필요 . 생성된 리포트는 다른 어플리케이션에 의해 유지되는 파일에서 얻은 직원에 대한 위치 데이터를 포함 .

업무 기술 (job description) 을 포함하는 업무 정보를 유지 , 조회 , 기록하는 기능이 필요 .

직원에 대한 업무 배정 (job assignment) 을 유지 , 조회 , 기록하는 기능이 필요 .

회사 내의 특정 위치에 있는 직원의 리스트를 포함한 위치 데이터(location data) 에서 위치를 조회하고 기록하는 기능이 필요 . 이 위치 데이터는 읽을 수만 있고 다른 어플리케이션에 의해서 유지됨 .


ILF 나 EIF 의 계산 예 : 프로세스 모델

EMPLOYEE-MAINTENANCECREATE-EMPLOYEEEMPLOYEE-INQUIRYUPDATE-EMPLOYEEDELETE-EMPLOYEEEMPLOYEE-REPORT

JOB-MAINTENANCECREATE-JOBJOB-INQUIRYUPDATE-JOBDELETE-JOBJOB-REPORT


프로세스 모델 ( 계속 )

JOB-ASSIGNMENT-MAINTENANCEASSIGN-EMPLOYEE-TO-JOBJOB-ASSIGNMENT-INQUIRYTRANSFER-EMPLOYEEEVALUATE-EMPLOYEEDELETE-ASSIGNMENTJOB-ASSIGNMENT-REPORT

LOCATION-REPORTINGLOCATION-INQUIRYLOCATION-REPORT


ILF 나 EIF 의 계산 예 : ER 다이어그램

EMPLOYEE

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

LOCATION

JOB_ASSGNMNT

JOB_DESCRIP


IMS 데이터베이스 구조

EMPLOYEE JOB

LOCATION_ASSGNMNT

LOCATION

JOB_ASSGNMNT

JOB_DESCRIP

LOCATION_ASSGNMNT

JOB_ASSGNMNT


엔터티 타입에 포함된 필드

EMPLOYEE 엔터티 타입Employee_NameSocial_Security_NumberNbr_DependentsType_Code (Salaried 혹은 Hourly)Location_Name ( 외래 키 )

SALARIED_EMPLOYEE 엔터티 타입Supervisory_Level

HOURLY_EMPLOYEE 엔터티 타입Standard_Hourly_RateCollective_Bargaining_Unit_Number

JOB 엔터티 타입Job_NameJob_NumberPay_Grade


엔터티 타입에 포함된 필드 ( 계속 )

JOB_DESCRIPTION 엔터티 타입 ( 사용자를 위한 서브그룹이 아닌 오직 구현만을 위한 엔터티 타입 )

Job_Number ( 외래 키 )Line_Number ( 사용자에게 중요하지 않고 오직 구현만을 위한 것 )Description_Line

JOB_ASSIGNMENT 엔터티 타입Effective_DateSalaryPerformance_RatingJob_Number ( 외래 키 )Employee_SSN ( 외래 키 )

LOCATION 엔터티 타입Location_NameAddressInteroffice_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 2Nbr_Dependents: DET 3Type_Code (Salaried 혹은 Hourly) : DET 4Location_Name ( 외래 키 ): DET5

SALARIED_EMPLOYEE 엔터티 타입 : EMPLOYEE 내의 RET 1Supervisory_Level: DET 6

HOURLY_EMPLOYEE 엔터티 타입 : EMPLOYEE 내의 RET 2Standard_Hourly_Rate : DET 7Collective_Bargaining_Unit_Number: DET 8

JOB 엔터티 타입 : ILF, RET 1Job_Name: DET 1Job_Number : DET 2Pay_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 1Salary : DET 2Performance_Rating : DET 3Job_Number ( 외래 키 ) : DET 4Employee_SSN ( 외래 키 ) : DET 5

LOCATION 엔터티 타입 : EIF, RET 1Location_Name : DET 1Address : DET 2Interoffice_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 에 있는 최소한

하나의 데이터가 유지되어야 한다 . 프로세스는 사용자에게 의미 있는 가장 작업 작업 단위이어야

한다 . 프로세스는 독립적이어야 하고 기능 점수를 계산하는

어플리케이션의 비즈니스를 일관된 상태로 두어야 한다 . 식별된 프로세스에 대해 다음 규칙 중 하나가 적용되어야 한다 .

1. 프로세싱 논리는 유일하거나 다른 외부 입력에 의해 수행되는 프로세싱 논리와 상이해야 한다 .

2. 데이터 요소의 집합은 다른 외부 입력에 관해 식별된 집합과 상이해야 한다 .

3. 참조되는 ILF 나 EIF 는 다른 외부 입력에 의해 참조되는 것들과 상이해야 한다 .


IFPUG 의 EI 트랜잭션 계산 규칙

제어 정보는 어플리케이션 경계 밖으로부터 수신되어야 한다 . 제어 정보는 어플리케이션의 요구사항을 준수하는지를

보장하기 위해 사용자에 의해 명세화되어야 한다 . 프로세스는 사용자에게 의미 있는 가장 작업 작업 단위이어야


어플리케이션의 비즈니스를 일관된 상태로 두어야 한다 . 식별된 프로세스에 대해 다음 규칙 중 하나가 적용되어야 한다 .

1. 프로세싱 논리는 유일하거나 다른 외부 입력에 의해 수행되는 프로세싱 논리와 상이해야 한다 .

2. 데이터 요소의 집합은 다른 외부 입력에 관해 식별된 집합과 상이해야 한다 .



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 의 총 개수



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 의 계산 예 : 프로세스 모델








ILF 와 EIF 의 계산 결과












ILF 와 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) 을 변경하는 것이다 .


외부 출력 ( 계속 )



– 예 : 여러 페이지로 구성된 리포트는 하나의 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 계산 규칙

데이터나 제어 정보는 어플리케이션 경계 밖으로 송신되어야 한다 .

EO 의 기본 프로세스의 프로세싱 논리는 다음 중 하나를 만족해야 한다 .

1. 최소한 하나의 수학식이나 계산을 포함2. 유도된 데이터의 생성3. 최소한 하나의 ILF 의 유지4. 어플리케이션의 동작을 변경

프로세스는 사용자에게 의미 있는 가장 작업 작업 단위이어야 한다 .

프로세스는 독립적이어야 하고 기능 점수를 계산하는 어플리케이션의 비즈니스를 일관된 상태로 두어야 한다 .


IFPUG 의 EO 계산 규칙 ( 계속 )

식별된 프로세스에 대해 다음 규칙 중 하나가 적용되어야 한다.

1. 프로세싱 논리는 유일하거나 다른 외부 출력에 의해 수행되는 프로세싱 논리와 상이해야 한다 .

2. 데이터 요소의 집합은 다른 외부 출력에 관해 식별된 집합과 상이해야 한다 . 동일한 필드에서 상이한 데이터를 가지는 개개인에 관해서 생성된

account statement 는 하나의 EO 상세한 수준과 개략적인 수준에서 각각 별도로 생성된 두 리포트는

유일한 프로세싱 논리와 계산을 가지므로 두 개의 EO 로 계산됨



EO 의 추가적인 예

알고리즘이나 계산이 필요한 리포트 데이터가 갱신되거나 유도될 때 혹은 기본 프로세스의 일부로 갱신될 때

다른 어플리케이션으로 송신되는 데이터 , 파일 , 메시지 생성시에 check number 와 check report 를 동시에 갱신하는 check 개발 프로젝트나 확장 프로젝트의 부분으로서 데이터가 이전될 때

컨버전 노력의 합계를 기록하는 컨버전 리포트» 어플리케이션 기능 점수가 아닌 프로젝트 기능 점수 계산의 일부로 포함됨

화면 상에 표시되거나 파일에 전달되는 유도된 정보 혹은 계산된 정보 계산을 필요로 하는 막대 그래프와 파이 챠트 전화로 전달되는 계산된 응답 사용자에게 전달되거나 무기시스템에서 다른 어플리케이션으로

전달되는 무기 발사 정보 현재까지의 사용액이 계산된 신용카드 분실 기록 제안된 보험 요율의 계산


EO 로 잘못 식별되는 예

부서별 리포트와 같이 상이한 데이터 값을 가지는 동일한 리포트 데이터를 보내는 어플리케이션 내에서 식 , 계산 , 유도된 데이터를 가지지 않고 ILF 를 유지하지 않는 리포트

» 대부분 EQ 상세한 리포트에 포함된 요약 필드

» 상세 리포트는 EO 데이터를 보내는 어플리케이션 내에서 식 , 계산 , 유도된 데이터를 가지지 않고 ILF 를 유지하지 않는 다른 어플리케이션으로 보내지는 파일

» 대부분 EQ 프로세싱 논리가 동일한 다중 미디어 스크린 데이터의 다시 보기나 취소 다른 프로세싱 논리가 없는 데이터 집합의 재정렬이나 재배열 다른 어플리케이션에 의해 읽히지만 , 기능 점수가 계산되는

어플리케이션에 저장된 참조 데이터 » 계산되는 어플리케이션에 의해 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 의 총 개수



어플리케이션의 경계를 들어가고 , 무슨 데이터가 언제 어떻게 기본 프로세스에 의해 검색 , 생성되는가를 명세하는데 필요하고 사용자가 유일하게 식별 가능한 반복되지 않는 필드 각각에 대해 하나의 DET 로 계산한다 .

» 종종 제어 정보 , 선택 정보 , 프로세싱 매개변수로 고려

어플리케이션의 경계를 나가고 , 사용자가 유일하게 식별 가능한 반복되지 않는 필드 각각에 대해 하나의 DET 로 계산한다 .

» 외래 키 속성과 제어 정보

만일 하나의 DET 가 경계를 모두 들어오고 나가면 , 기본 프로세스에 대해 단지 하나로만 계산




» 여러 메시지가 존재하더라도 메시지 전체를 하나의 DET 로 계산

동일한 논리 프로세스를 호출하는 여러 방법이나 다중 키가 존재하더라도 EO 의 액션을 명세하는 기능에 대해 하나의 DET 로 계산한다 .

» OK 버튼 , 기능 키 , 액션 키 , 마우스 클릭

페이지 번호 , 위치 정보 ( 행과 열 ), 페이지 명령 ( 이전 , 다음 ), 날짜 /시간 필드를 포함하는 페이지 변수나 시스템이 생성하는 스탬프는 계산하지 않는다 .

» DET 는 검색된 날짜를 포함하나 리포트 인쇄 날짜와 같은 시스템 생성 날짜는 포함하지 않음



리포트 제목 , 스크린 ID, 열 표제 (column heading), 필드 제목을 포함하는 리터럴은 계산하지 않는다 .

물리적으로는 여러 필드로 저장되었지만 사용자에 의해 단일 정보로 요구되는 논리적 필드에 대해서는 하나의 DET 로 계산한다 .

» 세 개의 필드로 저장되나 하나의 정보로 사용되는 날짜나 이름은 각각 하나의 DET 로 계산됨

그래픽 디스플레이에서 각 유형의 레이블과 동등한 각 수치에 대해 각각 하나의 DET 로 계산한다 .

» 예 : 파이 챠트는 두 개의 DET ( 범주 , 백분율 )

단일 단어 , 문장 , 단락 , 여러 단락으로 구성될 수 있는 텍스트 정보에 관해 하나의 DET 로 계산한다 .



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

EO 의 기본 프로세스에 의해 유지되는 각 ILF 에 대해서 하나의 FTR 로 계산한다 .

EO 에 의해 유지되고 읽히는 각 ILF 에 대해서 오직 하나의 FTR 로 계산한다 .


EO 의 계산 예 : 요구사항


업무 정보를 유지 , 조회 , 기록하는 기능이 필요 . 업무 기술 (Job Description) 은 80 문자 단위의 라인들로 구성되고 , 이 정보는 업무 (Job) 와 독립적으로 유지되지 않음




EI 의 계산 예 : 프로세스 모델























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



외부 조회 (EQ)

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


외부 조회 ( 계속 )



– 예 : 검색을 위해 5 개의 필드를 입력해야 하는 경우 , 필드 중 하나 혹은 일부를 입력하는 것은 기본 프로세스가 아님 .

– 완전한 트랜잭션이 되기 위해서는 정보의 요청 , ILF 나 EIF로부터 추출 , 정보의 전달을 포함

» 데이터는 조회 트랜잭션에 의해 처리되는 정보의 필드» 제어 정보는 어플리케이션의 기본 프로세스에 영향을 주는

데이터– 어떤 데이터가 언제 어떻게 처리되는지 명세– 그 자체가 기본 프로세스는 아님


외부 조회 ( 계속 ) 정의

» 프로세싱 논리 (processing logic) 는 기본 프로세스를 완성하기 위해 사용자에 의해 특별하게 요청되는 요구사항


예 : EQ 의 기본 프로세스가 다중 검증 , 필터 , 재정렬 등을 포함 – 프로세싱 논리 자체가 EI, EO, EQ 의 유일성을 결정하지 않음

재배열 , 재포맷팅 , 재정렬이 유일한 프로세싱 논리가 아님» 유도된 데이터는 추가적인 데이터를 생성하기 위해 기본

데이터의 변환을 통해 생성– 하나 이상의 ILF, EIF 로부터 정보의 직접적인 검색 , 컨버전 , 편집이 아닌 프로세싱을 요구

– EQ 는 유도된 데이터를 포함하지 않음 » 유지는 기본 프로세스를 통해 데이터를 수정하는 능력

– EQ 는 데이터를 유지하지 않음 . EI 나 EO 가 데이터를 유지함


IFPUG 의 EQ 계산 규칙

데이터나 제어 정보는 어플리케이션 경계 밖으로 송신되어야 한다 .

데이터나 제어 정보는 하나 이상의 ILF 나 EIF 로부터 검색되어야 한다 .

기본 프로세스의 프로세싱 논리는 유도된 데이터를 생성하지 않아야 한다 .

기본 프로세스의 프로세싱 논리는 수학식이나 계산을 포함하지 않아야 한다 .

프로세스는 ILF 를 유지하지 않아야 한다 . 프로세스는 사용자에게 의미 있는 가장 작업 작업 단위이어야


어플리케이션의 비즈니스를 일관된 상태로 두어야 한다 .


IFPUG 의 EQ 계산 규칙 ( 계속 )

식별된 프로세스에 대해 다음 규칙 중 하나가 적용되어야 한다.

1. 프로세싱 논리는 유일하거나 어플리케이션 내에서 다른 외부 조회에 의해 수행되는 프로세싱 논리와 상이해야 한다 .

2. 데이터 요소의 집합은 어플리케이션의 다른 외부 조회에 관해 식별된 집합과 상이하다 .

3. 참조되는 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 의 총 개수



어플리케이션의 경계를 들어가고 , 무슨 데이터가 언제 어떻게 기본 프로세스에 의해 검색 , 생성되는가를 명세하는데 필요하고 사용자가 유일하게 식별 가능한 반복되지 않는 필드 각각에 대해 하나의 DET 로 계산한다 .

» 종종 제어 정보 , 선택 정보 , 프로세싱 매개변수로 고려

어플리케이션의 경계를 나가고 , 사용자가 유일하게 식별 가능한 반복되지 않는 필드 각각에 대해 하나의 DET 로 계산한다 .

» 외래 키 속성과 제어 정보가 포함됨

만일 하나의 DET 가 경계를 모두 들어오고 나가면 , 기본 프로세스에 대해 단지 하나로만 계산




» 여러 메시지가 존재함에도 불구하고 메시지 전체를 하나의 DET 로 계산

동일한 논리 프로세스를 호출하는 여러 방법이나 다중 키가 존재하더라도 EQ 의 액션을 명세하는 기능에 대해 하나의 DET 로 계산한다 .

» OK 버튼 , 기능 키 , 액션 키 , 마우스 클릭

페이지 번호 , 위치 정보 ( 행과 열 ), 페이지 명령 ( 이전 , 다음 ), 날짜 /시간 필드를 포함하는 페이지 변수나 시스템이 생성하는 스탬프는 계산하지 않는다 .

» DET 는 검색된 날짜를 포함하나 리포트 인쇄 날짜와 같은 시스템 생성 날짜는 포함하지 않음



리포트 제목 , 스크린 ID, 열 표제 (column heading), 필드 제목을 포함하는 리터럴은 계산하지 않는다 .

물리적으로는 다중 필드로 저장되었지만 사용자에 의해 단일 정보로 요구되는 논리적 필드에 대해서는 하나의 DET 로 계산한다 .

» 세 개의 필드로 저장되나 하나의 정보로 사용되는 날짜나 이름은 각각 하나의 DET 로 계산됨

그래픽 디스플레이에서 각 유형의 레이블과 동등한 각 수치에 대해 각각 하나의 DET 로 계산한다 .

» 저장된 데이터로 퍼센트 값을 읽는 것처럼 계산 없이 그래프가 생성되면 , 그래프는 EQ 가 될 수 있음

단일 단어 , 문장 , 단락 , 여러 단락으로 구성될 수 있는 텍스트 정보에 관해 하나의 DET 로 계산한다 .



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


EQ 의 계산 예 : 요구사항


업무 정보를 유지 , 조회 , 기록하는 기능이 필요 . 업무 기술 (Job Description) 은 80 문자 단위의 라인들로 구성되고 , 이 정보는 업무 (Job) 와 독립적으로 유지되지 않음




EQ 의 계산 예 : 프로세스 모델























EQ 의 계산 예 : 복잡도 행렬


EQ 의 계산 예 : DET, FTR 에 관한 가정

EO 와 마찬가지로 EQ 도 데이터 검색을 위해 어플리케이션의 경계를 들어가는 필드와 제어 정보를 가질 수 있음

각 제어 정보가 디스플레이됨을 가정

오류 , 증명 , 확인 메시지에 대해 하나의 DET 로 계산

최소한 하나의 명령 키 (command key) 를 가짐

참조 파일은 하나만 존재» 검증을 위해 다른 파일을 참조할 필요가 없고 , 기본 파일을 제외한

파일에서 검색되는 필드가 없음


EQ 의 계산 예 : DET 와 FTR

EMPLOYEE-INQUIRY: FTR 1, DET 10

(메시지와 명령 키를 각각 하나의 DET 로 계산 )

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



4

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

일반 시스템 특성


개요 정보 시스템이 제공하는 기능에는 데이터 기능과 트랜잭션 기능에

의해 충분히 표현되지 않는 일반적인 요인들이 있고 , FPA 에 이를 반영하는 일반 시스템 특성 (General System Characteristics: GSC) 이 있음

값 조정 인자 (Value Adjustment Factor: VAF) 는 조정된 기능 점수(adjusted function point) 계산을 위한 승수 (multiplier) 로 사용됨

일반 시스템 특성 (GSC) 을 모두 무시하고 미조정된 기능 점수로 최종적인 기능 점수를 대치하려는 일부 경향이 있음

ISO 는 기능 점수 측정을 위해 일반 시스템 특성 (GSC) 을 배제하려는 작업을 진행 중임


개요 : 일반 시스템 특성 (GSC)

1. Data Communications2. Distributed data processing3. Performance4. Heavily used configuration5. Transaction rate6. Online data entry7. End user efficiency8. Online update9. Complex processing10. Reusability11. Installation ease12. Operational ease13. Multiple sites14. 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) + 0.65

» 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 PC1 일괄 처리이지만 원격 데이터 입력 혹은 원격 출력 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 온 라인 갱신이 없음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) + 0.65


5

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

기능 점수의 계산과 응용


개요

기능 점수를 계산하는 방법을 빠르고 쉽게 설명하기 위해 catalog 비즈니스의 예를 검토

데이터 기능과 트랜잭션 기능의 식별 규칙을 값 조정 인자 (VAF) 와 함께 사용하여 조정된 기능 점수 (adjusted function point) 를 계산

» 데이터 기능과 트랜잭션 기능은 각각의 복잡도 행렬에 기초하여 미조정된 기능 점수 가중치를 가짐

» 일반 시스템 특성 (GSC) 은 각각 독립적으로 계산되어 0 과 5 사이의 유일한 값이 할당되고 , 이 값들이 더해져 TDI 가 계산됨

» TDI 를 이용하여 VAF 를 계산하고 , VAF 는 미조정된 기능 점수에 곱해져 조정된 기능점수를 구함


조정된 기능 점수 계산





예 : Catalog 비즈니스

Business Catalog

Descriptions

Inventory

Sales

VendorAddressFile

Descriptions:add, change,delete

Descriptions:retrieve

Inventory:add, change,delete

Inventory:retrieve End-of-Month Report

Sales:add, change, delete

Sales:retrieve


예 : 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 - 42. Distributed data processing - 03. Performance - 34. Heavily used configuration - 25. Transaction rate - 36. Online data entry - 57. End user efficiency - 48. Online update - 39. Complex processing - 110. Reusability - 011. Installation ease - 012. Operational ease - 313. Multiple sites - 114. Facilitate change - 2

전체 영향의 정도 (TDI) : 31


예 : Catalog 비즈니스 – VAF 와 FP

VAF = (TDI × 0.01) + 0.65 = 0.96

FP (Adjusted Function Point) = UFP × VAF = 75


예 : Catalog 비즈니스 - worksheet

Function Point Calculation Worksheet

Project Number Project NameType 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

ComponentsExternal inputsExternal outputsExternal inquiriesInternal logical filesExternal interface files

Function Levels

Low Average High Total3 × 3 6 × 4 × 6 33 × 4 × 5 1 × 7 7 × 3 3 × 4 × 6 123 × 7 × 10 × 15 211 × 5 × 7 × 10 5

Total unadjusted Function Points (UFP) = 78


예 : Catalog 비즈니스 – worksheet (계속 )

General System Characteristics

Degree of Characteristic Influence1. Data communications 42. Distributed data processing 03. Performance 34. Heavily used configuration 25. Transaction rate 36. Online data entry 57. End user efficiency 4

Degree of Characteristic Influence8. Online update 39. Complex processing 110. Reusability 011. Installation ease 012. Operational ease 313. Multiple sites 114. Facilitate change 2

Total degree of influence (TDI) = 31

VAF Value adjustment factor = (TDI × 0.01) + 0.65 = 0.96FP Adjusted function point count = UFP × VAF = 75


기능 점수 계산 공식 : 개발 프로젝트

개발 프로젝트 기능 점수

개발 프로젝트 기능 점수 계산은 세 가지 기능의 컴포넌트로 구성된다 .

1. EI, EO, EQ 로 구성되는 어플리케이션의 미조정된 기능 점수 계산

2. 이전 데이터를 새로운 ILF 로 변환하는 컨버전 기능 ( 이 컴포넌트는 종종 이전 데이터 파일의 입력으로 구성된다 [EI 로 계산되거나 이미 계산된 새로운 ILF 로의 입력 데이터 ] 그리고 컨버전 리포트에 관한 EO 도 가능 )

3. 어플리케이션 값 조정 인자 (VAF)


기능 점수 계산 공식 : 개발 프로젝트 (계속 )

개발 프로젝트 기능 점수

개발 프로젝트 기능 점수 계산 공식

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

메뉴 중심 (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 WorksheetProject Number Problem B Project Name Locator ApplicationType 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

Low Average High Total × 3 × 4 × 6 × 4 × 5 × 7 × 3 × 4 × 6 × 7 × 10 × 15 × 5 × 7 × 10

Total unadjusted Function Points (UFP) =

문제 A 에 관한 미조정된 기능 점수를 계산하기 위해 , 앞에서 식별한 기능들과 일반 시스템 특성을 이용하여 기능 점수 계산 Worksheet 를 완성하라 .


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




Total degree of influence (TDI) =

VAF Value adjustment factor = (TDI × 0.01) + 0.65 = 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• E-mail 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 e-mail address• Task coordinator's name• Task coordinator's e-mail 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• Date closed for maintenance• Date reopened

데이터 기능과 트랜잭션 기능을 식별하고 복잡도를 추정하라 .


참고문헌 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 ( 계속 ) 메뉴에서 선택할 수 있는 기능은 다음과 같다 .


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 기능 점수 강좌에 관심이 있는 기업에 관한 정보를 유지하기 위한 간단한

어플리케이션을 구축하려고 한다 . 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 ( 계속 ) 메뉴에서 선택할 수 있는 기능은 다음과 같다 .


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 ( 계속 )


기초적인 사례 연구 : 문제 B

Function Point Calculation WorksheetProject Number Problem B Project Name Locator ApplicationType 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

Low Average High Total1 × 3 4 × 4 × 6 19 × 4 × 5 × 7 0 × 3 1 × 4 × 6 4 1 × 7 × 10 × 15 7 1 × 5 × 7 × 10 5

Total unadjusted Function Points (UFP) = 35

문제 A 에 관한 미조정된 기능 점수를 계산하기 위해 , 앞에서 식별한 기능들과 일반 시스템 특성을 이용하여 기능 점수 계산 Worksheet 를 완성하라 .


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




Total degree of influence (TDI) = 26

VAF Value adjustment factor = (TDI × 0.01) + 0.65 = 0.91FP Adjusted function point count = UFP × VAF = 31.85

Documents

기능 점수 분석 (Function Point Analysis)