기능 점수 분석 (Function Point Analysis)

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

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

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

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

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

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

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

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

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

10. 기능 점수 계산 준비 단계 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 내에 유지되는 정보의 검색과 디스플레이

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

43. DET counting example

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

45. IFPUG의 RET 계산 규칙 • ILF나 EIF의 선택적인서브 그룹이나 필수적인서브 그룹 각각을 하나의 RET로 계산한다. • 헤더, 트레일러, 별도의 텍스트 파일과 같이 활용되는 기술이나 방법론 때문에 존재하는 임의의 RET는 계산하지 않음 • 종종 둘 이상의 서브 그룹이 동일한 논리 파일(ILF 혹은 EIF)에 속함 • 이러한 RET들은 데이터의 저장과 논리 파일간의 관계를 생성하기 위해 이용되는 2차 키의 존재로 식별 가능 • 논리 파일의 데이터는 전형적으로 제3정규형의 데이터 • 만일 서브 그룹이 존재하지 않으면, ILF나 EIF를 하나의 RET로 계산한다.

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

47. 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

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

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

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