Function Point 절차 및 규칙 상세 2-1

1. 기능점수 측정 개요

기능점수 분석 개요

 기능점수 분석은 사용자 관점에서 소프트웨어 개발 규모를 측정하기 위한 표준 기법으로, 논리적 설계에 기초하여 사용자에게 제공되는 소프트웨어 기능들을 정량적으로 측정한다. 기능점수 분석의 목적은 사용자가 요구하여 제공받는 기능들을 구현 기술과 무관하게 측정하는 것이다.

 

기능점수 분석의 목적 사용자가 요구하여 제공 받는 기능들을 측정한다. 구현 기술과는 무관하게 소프트웨어 개발 및 유지보수 규모를 측정한다.

 

기능점수 분석의 이점은 조직에서 여러 가지 용도로 사용할 수 있다는 것이다. 기능점수 분석이 사용될 수 있는 용도로 다음을 들 수 있다.

패키지의 모든 기능을 측정하여 구매 어플리케이션 패키지의 규모를 결정하는 도구

사용자 요구를 만족시키는 특정 기능을 측정하여 어플리케이션 패키지가 사용자조직에 유익한지를 결정하는 도구

품질과 생산성 분석을 돕기 위해 소프트웨어 제품 단위를 측정하는 도구소프트웨어 개발 및 유지보수에 필요한 비용과 자원을 측정하기 위한 도구

소프트웨어 비교를 위한 정규화 요소

위의 기능점수 분석에 사용될 수 있는 용도 이외에도 IFPUG에서는 기능점수 분석의 이점에 관한 추가정보를 제공하고 있다.

기능점수 분석이 사용자 관점에서 소프트웨어 개발 규모를 측정하기 위한 기법이므로, 프로젝트나 어플리케이션에 대한 기능적 요구 정의에 있어서 사용자의 관점이 무엇인지 살펴볼 필요가 있다. 사용자 관점이란 사용자의 업무적 요구를 사용자의 용어를 사용하여 공식적으로 기술한 것을 의미한다. 기능점수 측정은 사용자와 개발자 모두에게 공통되는 언어로 기술된 정보를 사용해야 한다.

 

사용자 관점 업무 기능에 대한 기술이다. 사용자가 승인한다. 기능점수 측정에 사용될 수 있다. 물리적 형태(제안서, 요건문서, 상세사양서 등)는 다양할 수 있다.

 

기능점수를 측정하기 전에 어플리케이션 생명주기의 단계와 추정 또는 측정 여부를 결정하고, 모든 가정사항을 문서화 해야 한다. 추정을 통한 기능점수 분석은 알려지지 않은 기능과 그 기능의 복잡도에 대한 가정을 해야 하고, 측정을 통한 기능점수 분석은 모든 기능과 복잡도를 식별해야 한다. 프로젝트 초기 제안서만 존재하는 단계에서는 규모 추정은 가능하나, 규모 측정은 불가능하다.

 

생명주기 단계	규모 추정 가능 여부	규모 측정 가능 여부
제안	○	X
요구분석	○	○
설계	○	○
구축	○	○
인도	○	○
하자 유지보수	○	○

 

기능점수 측정 절차

그림1. 기능점수 측정 절차

 

기능점수 측정의 상위 절차는 다음과 같은 7단계로 이루어진다.

1단계 : 측정 유형 결정

2단계 : 측정 범위와 어플리케이션 경계 식별

3단계 : 데이터 기능 측정

4단계 : 트랜잭션 기능 측정

5단계 : 미조정 기능점수 결정

6단계 : 조정인자 결정

7단계 : 조정 기능점수 측정

  기능점수 측정의 첫 단계는 기능점수 측정 유형을 결정하는 것이다. 기능점수 측정은 프로젝트나 어플리케이션에 관련이 있고, 3가지 유형이 있다. 2단계에서는 측정 범위와 어플리케이션의 경계를 식별한다. 측정 범위는 특정한 기능점수 측정에 포함될 기능을 정의하고, 어플리케이션 경계는 측정 대상 소프트웨어와 사용자간의 경계선을 나타낸다. 3단계부터는 본격적인 측정이 이루어지는 단계로 3,4 단계에서는 데이터와 트랜잭션에 대한 기능 측정이 이루어진다. 데이터와 트랜잭션 기능에 대한 측정이 이루어지고 나면, 5단계에서 해당 프로젝트나 어플리케이션에 대한 미조정 기능점수가 계산되어 나오게 된다. 미조정 기능점수는 조정인자에 의해 조정되어 조정기능 점수로 계산된다. 이 때 조정인자를 결정하기 위한 단계가 6단계에서 이루어진다. 조정인자는 어플리케이션 사용자에게 제공되는 일반적 기능을 지칭하는 것으로, 어플리케이션의 일반 기능을 평가하는 14개의 일반 시스템 특성(GSC)으로 구성되어 있다. 각각의 영향도의 합을 이용하여 조정인자가 결정된다. 7단계에서는 각 측정 유형별로 존재하는 고유한 공식을 사용하여 조정 기능점수를 계산한다.

기능점수 측정의 각 단계에 대한 자세한 설명은 다음 장부터 계속된다.

    II. 측정 유형 결정

측정 유형	설명
개발 프로젝트	프로젝트가 종료되어서 인도된 소프트웨어의 최초 설치와 함께 사용자에게 제공된 기능을 측정하는 것
개선 프로젝트	기존 어플리케이션의 변경 부분을 측정하는 것으로, 프로젝트가 종료되어서 인도된 사용자 기능에 추가, 수정, 삭제한 부분을 의미. 개선 프로젝트에서 나온 기능이 설치되면 어플리케이션의 기능점수 측정치는 어플리케이션 기능들의 변동을 반영하기 위하여 수정되어야 함.(개선 프로젝트 단위)
어플리케이션	베이스라인 또는 설치된 기능점수 측정이라고도 부름. 사용자에게 제공된 어플리케이션의 현행 기능을 측정한 값. 개발 프로젝트 기능점수 측정이 완료되었을 때 초기화되고, 개선 프로젝트의 종료로 어플리케이션 기능이 변경될 때마다 수정됨.(일부 개선의 의미)

기능점수 측정 유형을 결정하기 위해서는 각 측정 유형의 정의에 맞게 해당 유형을 결정한다.

 

    III. 측정 범위와 어플리케이션 경계 식별측정 목적 수립측정 범위 식별어플리케이션 경계 식별문서화

측정 범위의 특성

• 규모측정 대상 소프트웨어의 집합을 정의한다.
• 기능점수 측정을 수행하려는 목적에 의해 결정된다
• 기능점수 측정 목적에 따른 해답을 얻는데 필요한 기능을 식별한다.
• 하나 이상의 어플리케이션이 포함될 수 있다.

 

측정 범위의 특성을 고려하면 기능점수 측정의 3가지 유형에 대한 기능점수 측정 범위를 다음과 같이 정의할 수 있다.

기능점수 측정 유형	측정 범위
개발 프로젝트	프로젝트 활동들에 의해 영향을 받는 모든 기능들(구축되거나 커스터마이즈 되는)을 포함한다.
개선 프로젝트	추가, 수정, 삭제되는 모든 기능을 포함하나, 영향을 받는 어플리케이션의 경계는 변하지 않는다. 하지만, 어플리케이션의 기능은 추가, 수정, 삭제된 기능들의 영향을 반영한다.
어플리케이션	목적에 따라 사용자가 사용하는 기능만을 포함할 수도 있고, 사용자에게 인도된 모든 기능을 포함할 수도 있다. 이 두 가지 측정 유형은 어플리케이션 경계는 동일하나, 측정 범위는 서로 다르다.

어플리케이션 경계 식별

 어플리케이션 경계란 측정 대상 소프트웨어와 사용자 간의 경계로서 어플리케이션의 내/외부를 구분하고, 어플리케이션에 의해 유지보수 되는 ILF를 구분하고, EIF를 식별하는데 도움을 준다. 어플리케이션 경계는 구현 기술과는 관계없이 식별된다.

어플리케이션 경계의 정의 무엇이 어플리케이션 외부인지 정의 내부 어플리케이션과 외부 사용자 간의 개념적 인터페이스 트랜잭션(EI,EO,EQ)에 의해 처리된 데이터가 어플리케이션에 들거나 나가는 세포막 같은 역할 어플리케이션에 의해서 유지보수 되는 논리 데이터(ILF)를 둘러쌈. 어플리케이션이 참조는 해도 유지보수는 하지 않는 논리 데이터(EIF)의 식별을 도움 어플리케이션에 대한 사용자의 외부 비즈니스 관점에 의존적이고, 기술 또는 구현상의 고려사항과는 독립적

 어플리케이션 경계의 설정은 기능점수 측정 결과에 영향을 미치므로 매우 중요하다. 어플리케이션의 경계는 사용자 관점에 의해 결정되는 것으로 그 초점은 사용자가 무엇을 이해하고 기술하느냐에 달려 있다. 또한, 사용자 관점에서 보는 기능영역에 기초하는 것이지 기술적 고려사항에 의해 결정되지 않는다. 그리고, 어플리케이션에 대해 이미 설정된 최초의 경계선은 측정 범위에 의해 영향을 받지 않는다.

경계 설정 규칙 사용자 관점에 의해 결정되는 것으로 그 초점은 사용자가 무엇을 이해하고 기술하느냐에 있다. 사용자가 보는 분리된 기능영역에 기초하는 것이지 기술적 고려사항에 의한 것이 아니다. 어플리케이션에 대해 이미 설정된 최초의 경계선은 측정 범위에 의해 영향 받지 않는다.

문서화

  측정 목적이 수립되고, 측정 범위가 결정되고, 어플리케이션 경계 설정이 모두 이루어진 뒤에는 그 내용에 해당하는 다음 항목들이 문서화 되어야 한다.

1. 측정 목적

2. 측정 범위

3. 어플리케이션 경계

4. 위와 관련된 모든 가정사항 

 

      IV. 데이터 기능 측정데이터 기능 유형 식별복잡도 및 기여도 결정

데이터 기능은 사용자의 내, 외부 데이터 요구사항을 충족시키기 위해 제공되는 기능으로, 내부논리파일(ILF: Internal Logical File)과 외부연계파일(EIF: External Interface File) 두 가지 유형으로 정의된다. 여기서 파일은 논리적으로 관련된 데이터 그룹을 의미한다.

데이터 기능의 측정은 다음의 두 단계의 절차에 따라 이루어진다. 첫 번째 데이터 기능 유형 식별 단계에서는 ILF와 EIF를 식별하고, 두 번째 단계에서는 데이터 기능으로 식별된 ILF와 EIF 각각에 대하여 복잡도를 결정하고 기여도를 계산한다.

①      데이터 기능 유형 식별

②      복잡도 및 기여도 결정

관련용어정의 제어정보(Control Information) : 측정 대상 어플리케이션의 단위 프로세스에 영향을 미치는 데이터로 언제 어떤 데이터를 어떻게 처리할 것인가를 명시 사용자 식별 가능(User Identifiable) : 사용자와 소프트웨어 개발자 모두가 이해하고 합의한 프로세스와(또는) 데이터 그룹에 대해 정의된 요구사항 유지된(Maintained) : 단위 프로세스를 통해 데이터를 변경할 수 있는 것 단위 프로세스(Element Process) : 사용자에게 의미를 주는 최소 단위의 활동으로 반드시 자기 완결적이라야 하며, 측정 대상 어플리케이션이 지원하는 비즈니스가 일관된 상태로 유지되어야 함. 사용자(User) : 기능적인 사용자 요구사항을 명시하는 사람이거나 또는 항상 소프트웨어와 상호작용 또는 의사소통을 하는 사람이나 사물

데이터 기능 유형 식별

  데이터 기능의 유형은 내부논리파일(ILF: Internal Logical File)과 외부연계파일(EIF: External Interface File) 두 가지가 있다.

  내부논리파일은 사용자가 식별할 수 있는 논리적으로 연관된 데이터 그룹 또는 제어정보로 어플리케이션 경계 내부에서 유지되고, 그 주요 의도는 측정 대상 어플리케이션에서 하나이상의 단위 프로세스를 통하여 유지되는 데이터를 보관하는데 있다.

  외부연계파일은 사용자가 식별할 수 있는 논리적으로 연관된 데이터 그룹 또는 제어정보로 다른 어플리케이션 경계 내부에서 유지 되고 측정 대상 어플리케이션이 참조한다. 그 주요 의도는 측정 대상 어플리케이션 경계 내부에서 하나 이상의 단위 프로세스를 통하여 참조된 데이터를 보관하는데 있다.

	내부논리파일(ILF)	외부연계파일(EIF)
정의	사용자가 식별할 수 있는 논리적으로 연관된 데이터 그룹 또는 제어정보로 어플리케이션 경계 내부에서 유지된다.	사용자가 식별할 수 있는 논리적으로 연관된 데이터 그룹 또는 제어정보로 다른 어플리케이션의 경계 내부에서 유지되고 측정 대상 어플리케이션이 참조한다.
주요의도	측정 대상 어플리케이션의 하나 또는 그 이상의 단위 프로세스를 통하여 유지되는 데이터를 보관하는데 있다.	측정 대상 어플리케이션 경계 내의 하나 또는 그 이상의 단위 프로세스를 통하여 참조된 데이터를 보관하는데 있다.(EIF로 측정된 것은 반드시 다른 어플리케이션의 ILF여야 함.)

내부논리파일과 외부연계파일의 차이점은 내부논리파일이 측정 대상 어플리케이션 경계 내에서 유지되나, 외부연계파일은 그렇지 않다는 것이다.

데이터 기능 유형 식별을 위해서는 각각의 데이터 기능 유형의 정의에 맞도록 식별 규칙에 따라서 데이터 기능 유형을 식별해야 한다. 데이터 기능 유형의 식별을 위하여 따라야 할 규칙은 다음과 같다.

유형	식별규칙
내부논리파일(ILF)	데이터 그룹 또는 제어정보는 논리적이고, 사용자가 식별 가능하여야 한다. 데이터 그룹은 측정되는 어플리케이션 경계 내부에서 단위 프로세스를 통해 유지되어야 한다.
외부연계파일(EIF)	데이터 그룹 또는 제어정보는 논리적이고, 사용자가 식별 가능하여야 한다. 데이터 그룹은 측정되는 어플리케이션의 외부에서 참조되어야 한다. 데이터 그룹은 측정되는 어플리케이션에 의해 유지되어서는 안 된다. 데이터 그룹은 다른 어플리케이션의 ILF로 유지되어야 한다.

내부논리파일(ILF)에 대한 몇몇 사례를 살펴보자. 이들은 단지 예에 불과하다. 내부논리파일로 측정되기 위해서는 위에 기술된 정의와 식별규칙을 따라야 한다.

• 사원정보, 제품정보, 급여정보, 거래자료, 판매실적자료, 고객정보 등의 어플리케이션 트랜잭션 자료
• 어플리케이션 내에서 유지보수 되는 도움말 자료
• 어플리케이션 내에서 유지보수 되는 에러/확인 메시지 자료
• 임시파일
• 동일 파일의 복사본
• 감사의 목적으로 유지되는 자료
• 정렬 파일
• 인덱스 파일
• 백업 및 복구 목적의 백업 자료
• 유지보수 되지 않는 미결파일

 

외부연계파일(EIF)에 대한 사례를 살펴보자. 다음은 EIF로 산정되는 사례들이다.

• 다른 어플리케이션에서 참조한 자료
• 어플리케이션 밖에서 유지보수 되는 도움말 자료
• 어플리케이션 밖에서 유지보수 되는 에러/확인 메시지 자료

 

EIF식별에서도 자주 일어나는 실수들이 있다. 아래의 사례들은 EIF로 식별되지 않아야 하는 것들이다.

• 다른 어플리케이션에서 받는 자료이지만, 측정 대상 어플리케이션 내의 ILF를 유지보수 하는 자료
• 임시파일
• 동일 파일의 복사본
• 감사 목적의 자료
• 정렬 파일

 

복잡도 및 기여도 결정

  데이터 기능 유형 식별 단계에서 식별된 내부논리파일(ILF)과 외부연계파일(EIF)의 수 그리고, 이들의 기능 복잡도에 따라 미조정 기능 점수에 대한 기여도가 결정된다. 이들 기능 복잡도는 데이터 요소 유형(DET: Data Element Type)과 레코드 요소 유형(RET: Record Element Type)의 수에 따라 결정된다.

데이터 요소 유형(DET)은 사용자가 식별 가능하고 반복되지 않는 유일한 필드를 말한다. 레코드 요소 유형(RET)은 ILF나 EIF안에서 사용자가 식별 가능한 데이터 요소의 서브그룹을 의미한다. 데이터 요소의 서브그룹으로는 선택적 서브그룹과 필수적 서브그룹의 두 가지 유형이 있다. 선택적 서브그룹은 사용자가 데이터의 인스턴스를 추가하거나 생성하는 단위 프로세스에서 사용할 수도 있고 사용하지 않을 수도 있는 서브그룹을 말한다. 필수적 서브그룹은 사용자가 적어도 하나 이상을 사용해야 하는 서브그룹을 말한다.

 

DET	사용자가 식별 가능하고 비반복적인 유일한 필드
RET	ILF나 EIF안에서 사용자가 식별 가능한 데이터 요소의 서브그룹

DET와 RET는 아래의 규칙에 따라 식별된다.

	식별규칙
DET	단위 프로세스의 실행을 통하여 ILF 또는 EIF에서 유지 또는 검색되고, 사용자가 식별 가능하며, 반복되지 않는 유일한 필드를 하나의 DET로 측정한다. 두 개의 어플리케이션이 같은 ILF 또는 EIF를 유지 또는 참조하되 각각 다른 DET를 유지 또는 참조한다면, 각각은 관련되는 필드만을 각자의 DET로 측정한다. 사용자의 요구로, 다른 ILF 또는 EIF와의 관계 설정에 필요한 각각의 데이터 항목을 하나의 DET로 측정한다.
RET	ILF나 EIF의 서브그룹(선택적/필수적) 각각을 하나의 RET로 측정한다. 서브그룹이 없다면, ILF나 EIF를 하나의 RET로 측정한다.

 

 

DET와 RET의 수가 위의 규칙에 따라 측정되면, 각각의 ILF와 EIF에 대한 복잡도를 결정한다. 복잡도가 평가되면 복잡도의 정도에 따라 미조정 기능점수로 변환할 수 있다. 복잡도 평가 및 미조정 기능점수 변환은 각각 표1. 복잡도 평가표와 표2. 미조정 기능점수 변환표를 이용한다.

 

ILF/EIF	1~19 DET	20~50 DET	51이상 DET
1 RET	낮음	낮음	보통
2~5 RET	낮음	보통	높음
6이상 RET	보통	높음	높음
EI	1~4 DET	5~15 DET	16이상 DET
0~1 FTR	낮음	낮음	보통
2 FTR	낮음	보통	높음
3이상 FTR	보통	높음	높음
EO/EQ	1~5 DET	6~19 DET	20이상 DET
0~1 FTR	낮음	낮음	보통
2~3 FTR	낮음	보통	높음
3이상 FTR	보통	높음	높음

표1. 복잡도 평가표

 

기능 유형	낮음	보통	높음
ILF	7	10	15
EIF	5	7	10
EI	3	4	6
EO	4	5	7
EQ	3	4	6

 

표2. 미조정 기능점수 변환표

 

주의해야 할 DET측정의 사례를 살펴보자.

• 여러 입력 필드에 저장되어 있지만 하나의 의미를 갖는 주소 또는 계좌번호 등은 1개의 DET
• 주키나 외부키로 2번 이상 나타나는 키 값은 1개의 DET
• 월별 자료를 보관하는 파일에서는 해당 월을 나타내는 필드를 1개, 월별 자료값을 보관하는 필드를 1개로 측정해서 2개의 DET
• 사원정보가 인사관리 어플리케이션에서도 유지되고, 보험 어플리케이션에서도 유지된다. 인사관리 어플리케이션에서는 사번, 이름, 주소 , 직책, 급여를 유지하고, 보험 어플리케이션에서는 급여만을 유지할 경우 인사관리 어플리케이션에서 사원정보 ILF의 DET는 5개이고, 보험 어플리케이션의 사원정보 ILF의 DET는 1개
• 감사의 목적으로 유지되는 이전과 이후 2개의 이미지는 2개의 DET

 

주의해야 할 RET측정의 사례를 살펴보자.

• 상품정보를 추가하기 위해서 상품과 상품설명을 함께 입력해야 하는 경우, 상품과 상품설명이 물리적으로 각각의 테이블에 존재하더라도 이들은 같이 유지되므로 하나의 ILF로 보고, 상품과 상품설명을 2개의 RET로 측정

 

       V. 트랜잭션 기능 측정단위 프로세스 식별단위 프로세스의 트랜잭션 유형 식별트랜잭션의 복잡도 및 기여도 결정

 

관련용어정의 제어정보(Control Information) : 측정 대상 어플리케이션의 단위 프로세스에 영향을 미치는 데이터로 언제 어떤 데이터를 어떻게 처리할 것인가를 명시 사용자 식별 가능(User Identifiable) : 사용자와 소프트웨어 개발자 모두가 이해하고 합의한 프로세스와(또는) 데이터 그룹에 대해 정의된 요구사항 유지된(Maintained) : 단위 프로세스를 통해 데이터를 변경할 수 있는 것 단위 프로세스(Element Process) : 사용자에게 의미를 주는 최소 단위의 활동으로 반드시 자기 완결적이라야 하며, 측정 대상 어플리케이션이 지원하는 비즈니스가 일관된 상태로 유지되어야 함. 사용자(User) : 기능적인 사용자 요구사항을 명시하는 사람이거나 또는 항상 소프트웨어와 상호작용 또는 의사소통을 하는 사람이나 사물 처리 로직(Process Logic) : 단위 프로세스를 완료하기 위해 사용자가 명확하게 요청하는 요구사항

 

단위 프로세스 식별

  단위 프로세스 식별이라 함은 해당 활동이 하나의 단위 프로세스로 식별될 수 있는지 여부를 판단하는 것으로, 단위 프로세스로 식별되어야 트랜잭션 기능 유형으로 구분될 수 있다. 단위 프로세스를 식별하기 위해서 어플리케이션에서 일어나는 사용자 활동을 살펴보고, 다음 식별 규칙을 만족시켜야 단위 프로세스로 식별된다.

단위 프로세스 식별 규칙

단위 프로세스는 사용자에게 의미 있는 활동의 최소 단위이어야 한다. 단위 프로세스는 자기 완결적이며, 측정되는 어플리케이션의 비즈니스를 일관된 상태로 유지해야 한다.

  단위 프로세스로 식별된 후에 해당 단위 프로세스를 트랜잭션 유형으로 구분하게 된다.

  단위 프로세스 식별의 사례를 들어보자.

• 어플리케이션에 신입사원 정보를 입력한다고 하자. 신입사원 정보에는 사원기본정보(사번, 이름, 직무, 주소, 부서)와 함께 부양가족, 급여정보가 포함되어야 한다. 이 때  사원기본정보와 부양가족, 급여정보가 모두 입력되는 것이 하나의 단위 프로세스로 식별된다.
• 고객에게 판매 영수증을 인쇄 출력하는 경우, ‘거래정보’ ILF의 ‘영수증 출력’을 출력으로 표시한다. 이 경우 영수증을 인쇄 출력하고 ‘영수증 출력’을 출력으로 표시하는 것은 하나의 단위 프로세스이다.
• 사원개인정보 입력과 함께 반드시 입력되어야 하는 인터뷰정보와 같이 2개의 입력 프로세스가 항상 순차적이고 종속적이라면, 하나의 단위 프로세스로 식별된다.

 

단위 프로세스의 트랜잭션 유형 식별

 트랜잭션 기능은 어플리케이션이 데이터를 처리하여 사용자에게 제공하는 기능을 나타내는 것으로, 그 유형은 외부입력(EI), 외부출력(EO), 외부조회(EQ) 세 가지로 구분된다.

 외부 입력(EI)은 어플리케이션 경계 밖에서 들어오는 데이터나 제어정보를 처리하는 단위 프로세스로, 주요 의도는 하나 이상의 ILF를 유지하거나 시스템의 동작을 변경시키는 것이다.

 외부 출력(EO)은 데이터나 제어정보를 어플리케이션 경계 밖으로 보내는 단위 프로세스로, 주요 의도는 데이터나 제어정보의 검색은 물로 처리 로직을 통해 사용자에게 정보를 제공하는 것이다. 처리 로직은 적어도 하나의 수학 공식, 계산 또는 파생 데이터를 포함하거나, 하나 이상의 ILF를 유지하거나, 시스템 동작을 변경시켜야 한다.

 외부 조회(EQ)는 데이터나 제어정보를 어플리케이션 경계 밖으로 보내는 단위 프로세스로, 주요 의도는 ILF나 EIF로부터 데이터나 제어정보를 검색하여 사용자에게 정보를 제공하는 것이다. 처리 로직은 수학 공식이나 계산을 포함하지 않으며, 파생 데이터도 생성하지 않아야 하고, 처리될 동안 ILF를 유지하지 않으며, 시스템 동작도 변경시키지 않는다.

	외부입력(EI)	외부출력(EO)	외부조회(EQ)
정의	어플리케이션 경계 밖에서 들어오는 데이터나 제어정보를 처리하는 단위 프로세스	데이터나 제어정보를 어플리케이션 경계 밖으로 보내는 단위 프로세스	데이터나 제어정보를 어플리케이션 경계 밖으로 보내는 단위 프로세스
주요의도	하나 이상의 ILF를 유지하거나 시스템의 동작을 변경하는 것	데이터나 제어정보를 검색하여 사용자에게 정보를 제공하는 것	데이터나 제어정보를 검색하여 사용자에게 정보를 제공하는 것

 

 

  단위 프로세스의 트랜잭션 유형을 식별하기 위해서 우선 단위 프로세스가 사용자에게 제공하고자 하는 기능의 주요의도를 파악하여 단위 프로세스 유형을 두 가지로 구분한다. 하나 이상의 ILF를 유지하거나 시스템의 동작을 변경하려는 주요의도라면 EI로 구분하고, 사용자에게 정보를 제공하려는 주요의도라면 EO나 EQ로 유형을 구분한다. 그리고 난 후, 최종적으로 EI, EO,EQ의 식별을 위해서는 각 유형의 식별규칙 사용하여 기능 유형을 결정한다.

  다음은 각 트랜잭션 기능의 유형을 식별하기 위해 사용되는 외부입력, 외부출력, 외부조회의 식별 규칙이다.

유형	식별규칙
외부입력(EI)	데이터 또는 제어정보를 어플리케이션 경계 밖에서 받아들인다. 어플리케이션 경계를 통해 들어온 데이터가 시스템의 동작을 바꾸는 제어정보가 아니라면, 적어도 하나의 ILF를 유지해야 한다. 식별된 단위 프로세스는 다음 셋 중 하나가 적용되어야 한다. 처리 로직이 어플리케이션 내 다른 외부 입력의 처리 로직과 구분될 수 있도록 고유해야 한다. 데이터 요소집합이 어플리케이션 내 다른 외부 입력의 데이터 요소집합과 구분되어야 한다. 참조한 ILF나 EIF는 어플리케이션 내 다른 외부 입력에 의해 참조된 ILF나 EIF와 구분되어야 한다.
외부출력(EO)	데이터 또는 제어정보를 어플리케이션 경계 밖으로 보낸다. 식별된 단위 프로세스는 다음 셋 중 하나가 적용되어야 한다. 처리 로직이 어플리케이션 내 다른 외부 출력의 처리 로직과 구분될 수 있도록 고유해야 한다. 데이터 요소집합이 어플리케이션 내 다른 외부 출력의 데이터 요소집합과 구분되어야 한다. 참조한 ILF나 EIF는 어플리케이션 내 다른 외부 출력에 의해 참조된 ILF나 EIF와 구분되어야 한다. 다음 처리 로직에 관한 규칙 중 하나를 추가로 충족해야 한다. 단위 프로세스의 처리 로직은 적어도 하나의 수학공식이나 측정을 포함한다. 단위 프로세스의 처리 로직은 파생 데이터를 만들어낸다. 단위 프로세스의 처리 로직은 적어도 하나의 ILF를 유지한다. 단위 프로세스의 처리 로직은 시스템의 동작을 변경한다.
외부조회(EQ)	데이터 또는 제어정보를 어플리케이션 경계 밖으로 보낸다. 식별된 단위 프로세스는 다음 셋 중 하나가 적용되어야 한다. 처리 로직이 어플리케이션 내 다른 외부 조회의 처리 로직과 구분될 수 있도록 고유해야 한다. 데이터 요소집합이 어플리케이션 내 다른 외부 조회의 데이터 요소집합과 구분되어야 한다. 참조한 ILF나 EIF는 어플리케이션 내 다른 외부 조회에 의해 참조된 ILF나 EIF와 구분되어야 한다. 다음 처리 로직에 관한 규칙을 모두 충족해야 한다. 단위 프로세스의 처리 로직은 ILF나 EIF로부터 데이터나 제어정보를 검색한다. 단위 프로세스의 처리 로직은 수학공식이나 측정을 포함하지 않는다. 단위 프로세스의 처리 로직은 파생 데이터를 만들지 않는다. 단위 프로세스의 처리 로직은 ILF를 유지하지 않는다. 단위 프로세스의 처리 로직은 시스템의 동작을 변경하지 않는다.

단위 프로세스의 트랜잭션 유형이 EI로 식별되는 사례를 살펴보자.

• 사원정보, 직무할당, 판매, 이체, 보험등록 등과 같이 ILF를 유지보수하기 위해 사용되는 트랜잭션 자료들
• 구 어플리케이션에서 신 어플리케이션으로 정보를 이전하는 기능
• 주문상품을 입력하고 수량을 입력하면 주문정보가 저장되기 전에 화면에 총 금액이 계산되면서 보여지는 경우, 주요 의도는 주문정보 ILF를 유지하는 것이므로 EI로 식별

 

단위 프로세스의 트랜잭션 유형이 EO로 식별되는 사례를 살펴보자.

• 계산되어지는 필드를 포함하고 있는 보고서 출력
• 파생 데이터를 포함하고 있는 온라인 조회 및 출력
• 부하사원이 할당된 모든 휴가를 사용했을 때, 사원의 휴가 사용 일수에 대한 통지가 자동으로 이루어지는 경우 수학공식이나 측정을 포함하고 있는 통지 메시지
• 매월 말일이 되면 어플리케이션이 자동으로 총 판매액이 계산되는 판매실적보고서를 출력하는 경우
• ‘거래정보’ ILF의 ‘영수증 출력’을 출력으로 갱신하면서, 고객에게 판매 영수증을 인쇄 출력하는 경우
• 한 어플리케이션에서 다른 어플리케이션으로 계산된 필드를 포함한 정보파일을 보내는 경우

 

단위 프로세스의 트랜잭션 유형이 EQ로 식별되는 사례를 살펴보자.

• 인사시스템의 부양가족 정보가 보험시스템으로 보내지는 것과 같이 다른 어플리케이션으로 수학공식이나 측정, ILF유지,파생데이터 생성의 처리 로직 없이 보내는 트랜잭션
• 인사시스템의 사원 정보를 조회하고, 보고하는 기능
• 입력 화면에서 입력을 돕기 위해 보여지는 드롭다운리스트 (단, 하드코딩 된 드롭다운리스트는 EQ로 식별되지 않는다.)
• 별도의 어플리케이션에 의해 유지되는 필드 도움말, 화면 도움말. 각 도움말은 어플리케이션 당 1번 측정
• 매월 말일이 되면 어플리케이션이 자동으로 총 계산되는 필드 없이 판매실적보고서를 출력하는 경우
• 한 어플리케이션에서 다른 어플리케이션으로 계산된 필드 없이 정보파일을 보내는 경우

 

단위 프로세스의 트랜잭션 유형으로 식별되지 않도록 주의가 필요한 사례를 살펴보자.

• 메뉴
• 하드코딩 된 드롭다운리스트

 

복잡도 및 기여도 결정

앞의 트랜잭션 유형 식별 단계에서 식별된 EI, EO와 EQ의 수와 이들의 기능 복잡도에 따라 미조정 기능 점수에 대한 기여도가 결정된다. 이들 기능 복잡도는 참조 파일 유형(FTR: File Type Reference)과 데이터 요소 유형(DET: Data Element Type)의 수에 따라 결정된다.

데이터 요소 유형(DET)은 사용자가 식별 가능하고 반복되지 않는 유일한 필드이다. 참조 파일 유형(FTR)은 트랜잭션 기능에 의해 읽히거나 유지되는 내부논리파일(ILF) 또는 트랜잭션 기능에 의해 읽히는 외부참조파일(EIF)이다.

DET	사용자가 식별 가능하고 비반복적인 유일한 필드
FTR	트랜잭션 기능에 의해 읽히거나 유지되는 내부 논리 파일 또는 트랜잭션 기능에 의해 읽히는 외부 참조 파일

EI, EO, EQ의 복잡도를 결정하기 위해 필요한 DET와 FTR의 수를 측정하기 위해서 DET와 FTR은 아래의 규칙에 따라 식별되어야 한다.

 

	식별규칙
DET	어플리케이션 경계로 들어오거나 나가며, 사용자가 인식할 수 있는 유일하고 반복되지 않는 각 필드를 하나의 DET로 측정한다. 단위 프로세스 수행 중 시스템에 의해 검색되거나 파생되어 ILF에 저장되는 필드로 어플리케이션 경계를 넘지 않는 것은 DET로 측정하지 않는다. 처리 중 발생한 에러를 표시하거나, 처리가 완료되었음을 표시하거나, 처리가 계속되어야 할지 여부를 묻고자 할 때 어플리케이션 경계 밖으로 내보내는 시스템의 메시지는 하나의 DET로 측정한다. 동일한 논리 프로세스를 기동 시키는 여러 가지 방법은 동일한 데이터로 간주하여 하나의 DET로 측정한다.
FTR	단위 프로세스 수행 중 유지되는 각 ILF를 하나의 FTR로 측정한다. 단위 프로세스 수행 중 읽혀진 각 ILF나 EIF를 각각 하나의 FTR로 측정한다. 단위 프로세스 수행 중 유지되면서 동시에 읽히는 각 ILF는 하나의 FTR로 측정한다.

 

	식별규칙
DET	어플리케이션 경계로 들어오거나 나가며, 사용자가 인식할 수 있는 유일하고 반복되지 않는 각 필드를 하나의 DET로 측정한다. 단위 프로세스 수행 중 시스템에 의해 검색되거나 파생되어 ILF에 저장되는 필드로 어플리케이션 경계를 넘지 않는 것은 DET로 측정하지 않는다. 처리 중 발생한 에러를 표시하거나, 처리가 완료되었음을 표시하거나, 처리가 계속되어야 할지 여부를 묻고자 할 때 어플리케이션 경계 밖으로 내보내는 시스템의 메시지는 하나의 DET로 측정한다. 동일한 논리 프로세스를 기동 시키는 여러 가지 방법은 동일한 데이터로 간주하여 하나의 DET로 측정한다. 문자 상수는 DET로 측정하지 않는다. 페이지 변수나 시스템 생성 소인은 DET로 측정하지 않는다.
FTR	단위 프로세스 수행 중 유지되는 각 ILF를 하나의 FTR로 측정한다. 단위 프로세스 수행 중 읽혀진 각 ILF나 EIF를 각각 하나의 FTR로 측정한다. 단위 프로세스 수행 중 유지되면서 동시에 읽히는 각 ILF는 하나의 FTR로 측정한다.

 

 

  DET와 FTR의 수가 위의 규칙에 따라 측정되면, 각각의 ILF와 EIF에 대한 복잡도를 결정한다. 복잡도가 평가되면 복잡도의 정도에 따라 미조정 기능점수로 변환할 수 있다. 복잡도 평가 및 미조정 기능점수 변환은 각각 표1. 복잡도 평가표와 표2. 미조정 기능점수 변환표를 이용한다.

ILF/EIF	1~19 DET	20~50 DET	51이상 DET
1 RET	낮음	낮음	보통
2~5 RET	낮음	보통	높음
6이상 RET	보통	높음	높음
EI	1~4 DET	5~15 DET	16이상 DET
0~1 FTR	낮음	낮음	보통
2 FTR	낮음	보통	높음
3이상 FTR	보통	높음	높음
EO/EQ	1~5 DET	6~19 DET	20이상 DET
0~1 FTR	낮음	낮음	보통
2~3 FTR	낮음	보통	높음
4이상 FTR	보통	높음	높음

표1. 복잡도 평가표

 

기능 유형	낮음	보통	높음
ILF	7	10	15
EIF	5	7	10
EI	3	4	6
EO	4	5	7
EQ	3	4	6

 

 

표2. 미조정 기능점수 변환표

트랜잭션 기능의 복잡도를 측정하는데 주의가 필요한 사례들을 살펴보자.

• ‘거래정보’ ILF의 ‘영수증 출력’을 출력으로 갱신하면서, 고객에게 판매 영수증을 인쇄 출력하는 경우, ‘영수증 출력’ 필드는 어플리케이션 경계를 넘지 않았으므로 DET로 측정하지 않는다.
• 고객정보가 이미 존재하는 고객이 고객정보를 입력하려고 할 경우, 시스템은 에러메시지를 표시한다. 이 경우 에러메시지는 하나의 DET로 측정한다.
• 사용자가 프로세스를 기동 시키기 위한 방법으로 엔터키를 누를 수도 있고, Function 키를 누를 수도 있고, 화면의 버튼을 클릭할 수 도 있는 경우 이들은 동일한 기능을 수행하기 때문에 하나의 DET로 측정한다.
• 날짜의 년,월,일이 물리적으로 여러 필드에 저장되어도 사용자가 단일 정보로 인식한다면 하나의 DET로 측정한다.
• 그래프는 범주 레이블과 수치에 상응하는 그래픽을 고려하여 2개의 DET로 측정한다. 범주가 2개로 나뉘어지는 그래프라면 수치에 상응하는 그래픽과 함께 3개의 DET로 측정한다.
• 보고서 출력 시 나타나는 보고서 제목 등은 문자상수로서 DET로 측정하지 않는다.
• 보고서 출력 등에서 보이는 페이지 수나 시스템 시간 등은 DET로 측정하지 않는다.