4. 데이터 기능 유형

1. 4. 데이터 기능 유형

2. 3. 데이터 기능 계산 5. 미조정 기능점수 결정 4. 트랜잭션 기능 계산 2. 계산 범위와 어플리케이션 경계 식별 1. 계산 유형 결정 7. 조정 기능점수 결정 6. 값 조정 인자 결정 주) 개정 사업대가기준의 기능점수는 “5. 미조정 기능점수”를 의미한다.

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

4. 데이터 기능 유형 • 내부 논리 파일 (Internal Logical Files: ILF) 내부논리파일(ILF)은 사용자가 식별할 수 있는 논리적으로 연관된 데이터 그룹 또는 제어정보로 어플리케이션 경계 내부에서 유지된다. 내부논리파일(ILF)의 주요 의도는 계산 대상 어플리케이션의 하나 또는 그 이상의 단위 프로세스를 통하여 유지되는 데이터를 보관하는데 있다. • 외부 인터페이스 파일 (External Interface Files: EIF) 외부 인터페이스 파일(EIF)은 사용자가 식별할 수 있는 논리적으로 연관된 데이터 그룹 또는 제어정보로, 다른 어플리케이션의 경계 내부에서 유지되고 계산 대상 어플리케이션이 참조한다. 외부 인터페이스 파일(EIF)의 주요 의도는 계산 대상 어플리케이션 경계 내의 하나 또는 그 이상의 기본 프로세스를 통하여 참조된 데이터를 보관하는데 있다. 이것은 특정 어플리케이션에서 외부 인터페이스 파일(EIF)로 계산된 것은 반드시 다른 어플리케이션의 내부논리파일에 존재해야 함을 의미한다. • ILF와 EIF의 차이점 내부논리파일이 계산 대상 어플리케이션 경계 내에서 유지되는 반면 외부 인터페이스 파일(EIF)은 그렇지 않다.

5. ILF의 식별 규칙 • ILF를 식별하기 위해서는, ILF의 정의를 만족하는 데이터 그룹이나 제어 정보를 찾아야 하고, 다음과 같은 규칙들을 반드시 따라야 한다. • 데이터 그룹 또는 제어정보는 논리적이고, 사용자가 식별 가능하여야 한다. • 데이터 그룹은 계산되는 어플리케이션 경계 내부에서 기본 프로세스를 통해 유지되어야 한다.

6. EIF의 식별 규칙 • EIF를 식별하기 위해서는, EIF의 정의를 만족하는 데이터 그룹 또는 제어 정보를 찾아야 하고, 다음과 같은 규칙들을 반드시 따라야 한다. • 데이터 그룹 또는 제어 정보는 논리적이고, 사용자가 식별 가능해야 한다. • 데이터 그룹은 계산되는 어플리케이션의 외부에서 참조되어야 한다. • 데이터 그룹은 계산되는 어플리케이션에 의해 유지되어서는 안 된다. • 데이터 그룹은 다른 어플리케이션의 ILF로 유지되어야 한다.

7. 데이터 기능의 복잡도 요소-RET • 레코드요소유형 (Record Element Type: RET) 레코드요소유형(RET)은 ILF나 EIF 안에서 사용자가 식별 가능한 데이터 요소의 서브그룹으로, 다음 두 가지 유형이 있다. 선택적(Optional) 필수적(Mandatory) • 선택적 서브그룹이란 사용자가 데이터의 인스턴스(Instance)를 추가 또는 생성하는 기본 프로세스에서 서브그룹을 사용할 수도 있고 사용하지 않을 수도 있는 것을 말한다. • 필수적 서브그룹은 사용자가 적어도 하나 이상의 서브그룹을 사용해야 하는 것을 말한다. 예: 인사관리시스템에서 사원 정보는 기본사항만 입력하면 레코드는 추가된다. 모든 사원 정보는 기본사항 외에도 월급제 또는 시간제 정보가 있고, 경우에 따라서 부양 가족에 관한 정보도 가질 수 있다. 이럴 경우 사원 정보의 레코드요소유형(RET)은 아래와 같이 3개의 서브그룹을 가진다. 월급제 사원(필수적); 기본사항 정보를 포함한다. 시간제 사원(필수적); 기본사항 정보를 포함한다. 부양 가족(선택적)

8. 데이터 기능의 복잡도 요소-RET • RET를 계산할 때 적용할 규칙은 다음 중 하나이다. • ILF나 EIF의 서브그룹(선택적/필수적) 각각을 하나의 RET로 계산한다. • 서브그룹이 없다면 ILF나 EIF를 하나의 RET로 계산한다

9. Employee Dependent Salaried Hourly RET의 예 • Users require that employee can be either salaried or hourly and each contain different types of information • Users also require that dependent information be included as part of the employee information • Count as 1 ILF with 3 RETs : Salaried Employee, Hourly Employee, and Dependent

10. 데이터 기능의 복잡도 요소-DET • 데이터 요소 유형 (Data Element Type: DET) 정의 데이터 요소 유형(DET: Data Element Type)은 사용자가 식별 가능하고 비반복적인 유일한 필드를 말한다. • DET 계산 규칙 • 기본 프로세스의 실행을 통하여 ILF 또는 EIF에서 유지 또는 검색되고, 사용자가 식별 가능하며, 반복되지 않는 유일한 필드를 하나의 DET로 계산한다. 예: 여러 필드에 저장되어 있는 계정 번호는 1개의 DET로 계산한다. 예: 감사 목적으로 유지되는 10개 필드 그룹의 이전 및 이후 이미지는 각각을 1개의 DET로 간주하여 총 2개의 DET로 계산한다. 예: ILF로 유지되는 고객주문정보로부터 계산된 판매세금과 같이 기본 프로세스의 수행으로 나온 결과값도 고객주문 ILF에 있어서 1개의 DET로 계산한다. 예: 청구 파일이나 타임 스탬프와 같은 필드에 저장된 특정 품목의 가격에 접근한 정보도 사용자가 요구하면 DET로 계산한다. 예: ILF나 EIF상에서 주키(사원 레코드 상)와 외래 키(부양가족 레코드 상) 로 2 번 이상 나타나는 키 값(사번)은 1개의 DET로 계산한다. 예: ILF와 EIF상에서 1년분 예산을 월별로 보관하고 있다면, 각 월의 예산을 보관하는 필드를 1개의 DET로 계산하고, 해당 월을 나타내는 필드를 1개의 DET로 계산한다.

11. 데이터 기능의 복잡도 요소-DET • 두개의 어플리케이션이 같은 ILF 또는 EIF를 유지 또는 참조하되 각각 다른 DET를 유지 또는 참조한다면, 각각은 관련되는 필드만을 각자의 DET로 계산한다. 예: 어플리케이션 A는 주소 정보로 시/도, 시/군/구, 읍/면/동, 번지 그리고 우편 번호를 별도로 식별하였고, 어플리케이션 B는 주소 정보를 필드별로 구분하지 않고 전체를 하나로 식별하였다. 이 경우 어플리케이션 A는 5개의 DET로 계산하고, 어플리케이션 B는 1개의 DET로 계산한다.예: 어플리케이션 X는 주민등록번호, 성명, 연락처, 주소, 우편번호를 포함한 ILF를 유지하고 있고, 어플리케이션 Z는 성명, 연락처, 주소만을 유지하고 있다. 이 경우 어플리케이션 X는 5개의 DET로, 어플리케이션 Z는 3개의 DET로 계산한다. • 사용자의 요구로, 다른 ILF 또는 EIF와의 관계 설정에 필요한 각각의 데이터 항목을 하나의 DET로 계산한다. 예: 사원 정보는 인사관리시스템에서 하나의 ILF로 유지되고, 사원의 직책은 사원 정보에 포함되어 있다. 한편 직무 명은 조직 내 직무 정보 ILF에 포함되어 있는 것으로 사원과 직무를 연결시키는 고리역할을 한다. 따라서 직무 명은 DET 규칙에 따라 1개의 DET로 간주한다. 이러한 유형의 데이터 요소를 외래 키라 부른다. 예: 객체지향 어플리케이션에서 사용자는 이미 별개의 ILF 또는 EIF로 식별된 객체 클래스들간의 연동을 필요로 한다. 즉, 근무지 정보 EIF와 사원 정보 ILF가 있어서 각각은 근무지라는 데이터 요소로 연동된다. 이 경우 DET 규칙에 따라 근무지 정보 EIF의 근무지를 1개의 DET로 식별하고, 또한 사원 정보 ILF의 근무지를 1개의 DET로 식별한다.

12. Employee Number(K) Name Address City State Zip Job Employee Data One to many All entries in the dependent table must be associated with an employee. Employee Number(FK) Dependent Name Address City State Zip Relation Dependent Data DET의 예 Employee ILF 2 RETs 13 DETs

13. DET counting example

14. DET counting example 결과 • 둘 이상의 어플리케이션이 DET를 제외하고는 동일한 ILF나 EIF를 유지, 참조할 때에는 각 어플리케이션이 이용하는 DET만을 계산한다. • counting example: A(8), B(7), C(2)

15. ILF 예제 END END USER USER 1.0 1.0 VALIDATE AND AUTHORIZE UPDATE ORDERS Order Logon Updated Order SECURITY TABLE ORDER FILE 1.0 1.0 Sales STORE SORT Name and Address SALES PROCESS Sorted Sales CHECK SALES OLD SALES MASTER 2.0 PERSONNEL FILE Check UPDATE SALES FILE EMPLOYEE NEW SALES MASTER

16. ILF 예제 • Entering orders • Updating employee data • Changing security access Application Being Considered process Internal Logical File process process Batch updates process Open Order Report

17. Sales Representative Table ILF 예제 • Customer Table

18. EIF 예제 ZIP CODE TABLE CALENDAR FILE END USER 1.0 VALID ZIP CODES MONTH END DATES VALIDATE ZIP CODE FINANCIAL REPORTS UPDATES EMPLOYEE FILE END USER 1.0 GEN LEDGER FILE 2.0 CREATE FINANCIAL REPORTS UPDATE EMP INFO UPDATES FINANCIAL INFO 1.0 RECEIPTS 1.0 NAME AND ADDRESS STORE VALIDATE RECEIPTS PROCESS EXPENSE CHECKS VALID P.O.s P.O. FILE PERSONNEL FILE CHECKS 2.0 P.O. FILE EMPLOYEE UPDATE P.O. FILE RECEIPT UPDATES

19. Application1 Application2 Employee File Department File Internal Logical File EIF Internal Logical File Process referenced Batch Process Active Employees By DepartmentReport Print a report of all active employees by department showing department name EIF 예제

20. ILF/EIF 복잡도 행렬 ILF 가중치 낮음 = 7 보통 = 10 높음 = 15 EIF 가중치 낮음 = 5 보통 = 7 높음 = 10

21. ILF/EIF 계산 힌트 • 데이터가 사용자의 구체적인 요구사항을 지원하는 논리적 데이터 그룹인가? • 어플리케이션은 다수의 프로세스에서 동일한 ILF 또는 EIF를 여러 번 사용 할 수 있으나, ILF 또는 EIF는 오직 한번만 계산 되어야 한다. • 어떤 논리적 파일도 같은 어플리케이션 내에서 ILF와 EIF로 동시에 계산되어서는 안 된다. 만약 그 데이터 그룹이 양쪽의 규칙을 모두 만족한다면, 하나의 ILF로만 계산한다. • 어떤 데이터 그룹이 ILF 또는 EIF로 계산되지 않는다면, 그 데이터 그룹을 포함하는 ILF 또는 EIF의 DET로 간주하되, 그 데이터 그룹의 각 데이터 요소를 하나의 DET로 계산한다. • 데이터를 사용자 관점에서 논리적으로 볼 때, 하나의 물리적 파일이나 테이블 또는 객체 클래스를 같은 하나의 논리적 파일로 간주하지 마라. • 어떤 저장 기술에서의 관계형 DBMS 테이블이나 단순 순차 파일 또는 객체 클래스가 ILF나 EIF와 밀접하게 관련되었다고 해서 이들이 항상 1:1의 물리-논리 관계가 있다고 간주하지 마라. • 모든 물리적 파일이 반드시 계산되어져야 한다거나, ILF 또는 EIF의 일부로 포함되어야 한다고 간주하지 마라.

22. ILF/EIF 계산 힌트 • 데이터는 어디에서 유지되는가? 어플리케이션 경계의 내부인가, 외부인가? • 작업흐름도를 살펴보라. • 프로세스 기능 분해도상에서 사용자와 다른 어플리케이션 간에 인터페이스가 발생하는 곳이 어디인가 식별하라. • 힌트를 얻기 위하여 프로세스 다이어그램을 검토한다. • 하나 이상의 어플리케이션에서 유지되는 ILF는 각 어플리케이션에서 각각의 ILF로 식별하되, 각 어플리케이션에서 사용하는 DET들만으로 ILF를 식별하고 그때의 DET 수를 ILF의 복잡도 결정에 사용한다. • ILF상의 데이터는 어플리케이션의 기본 프로세스를 통해서 유지되는가? • 어떤 ILF나 EIF가 같은 어플리케이션에서 아무리 여러 번 사용된다 하더라도 계산은 오직 한번만 한다. • 하나의 기본 프로세스가 하나 이상의 ILF를 유지할 수 있다. • 힌트를 얻기 위하여 프로세스 다이어그램을 검토한다. • 하나 이상의 어플리케이션에서 유지되는 ILF는 각 어플리케이션에서 별도의 ILF로 식별한다.

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

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

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

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

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

28. EMPLOYEE JOB LOCATION_ ASSGNMNT JOB_ ASSGNMNT JOB_ DESCRIP SALARIED HOURLY LOCATION IDMS 데이터베이스 구조

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

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

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

32. ILF나 EIF의 계산 예: 복잡도 행렬

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

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

35. 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 Employee_SSN (외래 키) : DET 3

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

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