4. 데이터 기능 유형

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

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

데이터 기능 유형 내부 논리 파일 (Internal Logical Files: ILF) 내부논리파일(ILF)은 사용자가 식별할 수 있는 논리적으로 연관된 데이터 그룹 또는 제어정보로 어플리케이션 경계 내부에서 유지된다. 내부논리파일(ILF)의 주요 의도는 계산 대상 어플리케이션의 하나 또는 그 이상의 단위 프로세스를 통하여 유지되는 데이터를 보관하는데 있다. 외부 인터페이스 파일 (External Interface Files: EIF) 외부 인터페이스 파일(EIF)은 사용자가 식별할 수 있는 논리적으로 연관된 데이터 그룹 또는 제어정보로, 다른 어플리케이션의 경계 내부에서 유지되고 계산 대상 어플리케이션이 참조한다. 외부 인터페이스 파일(EIF)의 주요 의도는 계산 대상 어플리케이션 경계 내의 하나 또는 그 이상의 기본 프로세스를 통하여 참조된 데이터를 보관하는데 있다. 이것은 특정 어플리케이션에서 외부 인터페이스 파일(EIF)로 계산된 것은 반드시 다른 어플리케이션의 내부논리파일에 존재해야 함을 의미한다. ILF와 EIF의 차이점 내부논리파일이 계산 대상 어플리케이션 경계 내에서 유지되는 반면 외부 인터페이스 파일(EIF)은 그렇지 않다. Data Function Type - Data Function Type에는 Internal logical Files(ILF), External Interface Files(EIF)이 있다. - Data Function은 내부 혹은 외부 데이터 요구사항을 만족하는 기능을 사용자에게 제공한다 - File은 물리적인 File을 의미하는 것이 아니라 논리적으로 묶여진 물리적 데이터의 그룹을 말한다 Internal Logical Files (ILF) - 사용자 어플리케이션 영역 내에 존재하는 사용자가 식별 가능한 제어정보(Control information) 또는 논리적으로 연관된 data들의 집합을 의미한다. External Interface Files(EIF) - EIF는 다른 어플리케이션 경계 내에서 수정되어지는 사용자가 인식 가능한 논리적으로 연관된 데이터의 그룹이나 어플리케이션에 의해서 참조되는 제어 정보를 말한다. - 한 어플리케이션에서 EIF로 계산되는 파일은 다른 어플리케이션에서 ILF로 계산된다.

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

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

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

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

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 Employee Dependent Hourly Salaried

데이터 기능의 복잡도 요소-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로 계산한다.

데이터 기능의 복잡도 요소-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로 식별한다.

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

DET counting example DET DET Usage DETs Counted Part number Primary key to A, B, and C DET to A, B, and C Part name Maintained by A Referenced by B and C DET to A DET to B and C Weekly usage Maintained by B DET to B Department using Purchase price Referenced by B Supplier name Reference by B Supplier street address Supplier city Supplier state Supplier postal code Supplier total address, read as one block of data 1 DET to A

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

ILF 예제 END END USER USER 1.0 1.0 VALIDATE AND AUTHORIZE UPDATE ORDERS Logon Updated Order ORDER FILE SECURITY TABLE 1.0 1.0 Sales STORE SORT Name and Address SALES Sorted Sales PROCESS CHECK OLD SALES MASTER 사용자는 온라인으로 주문 정보를 입력한다. 입력되는 정보는 주문 상품, 주문 개수, 주문자 이름, 발송 주소, 결재 방법 등의 데이터를 입력한다. 입력한 정보는 주문파일에 저장된다. 입력된 정보는 추후에 수정, 삭제 되며 조회 가능하다. 사용자는 사내 시스템을 사용하기 위해 로그인을 해야 한다. 사용자가 ID, Password를 입력하면 Security Table을 조회하여 등록된 사용자만 접속을 허용하도록 한다. 일과 시간이 끝나면 특정한 시간에 임시 파일에 저장되어 있던 데이터들이 배치작업을 통해서 일괄적으로 메인 데이터 베이스에 저장된다. 배치 작업에 대한 정보는 배치작업설정파일에 저장되며 사용자가 옵션을 수정 할 수 있다. 일일 판매 현황 정보를 정렬하여 Sales 파일에 저장한다. 저장된 Sales파일과 Old Sales Master 파일을 종합하여 최종 New Sales Mater 파일에 저장한다. Sales, Old Sales Mater는 New Sales Master파일에 저장하기 위한 일종의 임시파일과 같은 성격을 띤다. 따라서 이 때는 1 ILF(New Sales Master) 2 RET(Old Sales Master, Sales)가 된다. SALES 2.0 PERSONNEL FILE UPDATE Check SALES FILE EMPLOYEE NEW SALES MASTER

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

ILF 예제 Customer Table Sales Representative Table ILF, DET, RET의 개수는 각각 몇 개인가 ? Customer , Sales Representative Table은 하나의 ILF라고 볼 수 있는가? 2 ILF, 1 RET each 1 ILF, 2 RET

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 2.0 GEN LEDGER FILE CREATE FINANCIAL REPORTS UPDATE EMP INFO UPDATES FINANCIAL INFO 1.0 RECEIPTS 1.0 NAME AND ADDRESS STORE VALIDATE RECEIPTS PROCESS EXPENSE CHECKS 사용자는 주소 정보를 입력하기 위해서 우편 번호를 조회하여 해당 주소를 사용자 정보에 입력한다. 우편번호와 매칭되는 주소 정보는 Zip Code 파일에 존재하며 다른 어플리케이션에서 관리된다. 매월 말 정기적으로 시스템은 월간 매출현황 보고서를 출력한다. 해 당월의 말일에 대한 정보는 Calendar File에 저장되어 있으며 다른 어플리케이션에서 관리된다. 인사정보에 친분이 관계사 임직원을 등록하는 항목이 있다. 사용자는 이름을 입력하여 관계사 임직원 파일에서 해당 인물을 조회하여 양식에 해당 임직원의 이름과 관계 등을 등록한다. VALID P.O.s P.O. FILE PERSONNEL FILE CHECKS 2.0 P.O. FILE UPDATE P.O. FILE EMPLOYEE RECEIPT UPDATES

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

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

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

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

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

ILF나 EIF의 계산 예: 복잡도 행렬 레코드 요소 유형 (RET) 데이터 요소 유형 (DET) 1 - 19 20 - 50  51 < 5 낮음(low) 보통(average) 2 - 5 높음(high) > 5

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

ILF나 EIF의 계산 예: 복잡도 ILF와 EIF에 관한 복잡도 행렬에 의해 3개의 low ILF, 한 개의 low EIF 레코드 요소 유형 (RET) 데이터 요소 유형 (DET) 1 - 19 20 - 50  51 < 5 낮음(low) 보통(average) 2 - 5 높음(high) > 5

ILF, EIF 계산 예: 미조정 기능 점수 3개의 low ILF: 21, 한 개의 low EIF: 5 기능 요소 기능 수준 보통(average) 높음(high) 내부 논리 파일(ILF)  7  10  15 외부 인터페이스 파일(EIF)  5 외부 입력(EI)  3  4  6 외부 출력(EO) 외부 조회(EQ)