기능점수_개요

1. 기능점수 개요(Function Point, FP)

• IBM사의 Allan J. Albrecht에 의해 처음 개발되었다.
• 사용자가 요구한 기능을 기반으로 전체 시스템의 규모를 산정한다.
• 장점
  • 개발에 사용된 기술, 환경, 언어, 도구, 개발자 능력으로부터 독립적이다.
  • 사용자 요구사항만으로 규모 산정이 가능하기 때문에 소프트웨어 개발 초기단계에 산정이 가능하다.
• 단점
  • 프로젝트 초기 단계에 모든 요구사항을 파악하기에 어렵다면, 산정이 어려움
  • 알려지지 않은 기능의 복잡도가 있다면 산정이 어려움

 

2. 기능점수 측정 방식 절차

측정유형 결정 → 측정범위와 앱 경계를 식별 → 데이터 기능 측정 → 트랜잭션 기능 측정 → 기능 점수 산정

 

2.1. 측정 유형 결정

• 측정 유형은 개발 프로젝트, 개선 프로젝트, 애플리케이션 세가지로 구분된다.
  • 개발 프로젝트
    • 신규 소프트웨어를 개발하는 시점부터 유지보수 전까지 최초기능의 크기를 산정
    • 국내 소프트웨어 사업대가를 기준으로 기능점수방법을 권장함
  • 개선 프로젝트
    • 소프트웨어 개발 끝난 시점부터, 시스템 수정/변경이 필요한 프로젝트에서의 크기를 산정
  • 애플리케이션
    • 현재 운영 중인 시스템을 대상으로 크기를 산정하는 것
    • 개발 프로젝트에서 측정한 기능점수와 애플리케이션의 기능점수를 비교해 비용 측정 정확도를 계산함

2.2. 측정범위와 앱 경계를 식별

• 프로젝트 규모를 산정할 대상을 명확하게 식별하기 위한 단계로, 측정 대상은 하나 이상의 Application이다.
• 이 Application 들은 각각 구분이 가능해야 한다. 즉, App간의 경계가 존재한다.
• 하나의 트랜잭션 의해 처리한 데이터가 측정대상 App에 들어가거나 나가는 것을 App의 경계라 한다.
• 예시) 하나의 웹 시스템에는 데이터를 관리하는 App, 결제를 관리하는 App, 사용자 UI 등이 존재한다. 이때, 측정 대상은 3개 이상의 App이 되며 각각의 App끼리 명확히 구분이 되어야 한다. 이 App끼리 오가야 하는 데이터가 있다면, 이 데이터는 App의 경계를 오간 것

2.3. 데이터 기능 측정

• 사용자의 내/외부 데이터 요구사항을 충족하기 위해 제공되는 기능을 측정한다.
• 데이터는 크게 내부와 연관있는 데이터와 외부와 연관있는 데이터로 나뉜다.
  • 내부 논리 파일 (Internal Logical File, ILF)
    • 데이터가 하나의 App 내에서만 관리되고 유지(CRUD)되는 파일
    • 이 데이터의 존재를 사용자도 알고 있어야 함
    • 시스템의 필요에 의해 사용되는 데이터(ex. Flag)는 데이터 복잡도를 측정할 때 카운팅 되지 않는다.
  • 외부 연계 파일 (External II File, EIF)
    • 데이터가 하나의 App 외부에서 관리되고 유지되는 파일
    • 예시) 회원가입에서 주소지 정보를 입력받는다. 이때 주소지는 나라에서 관리하는 주소지, 우편번호를 읽어들이는데 이는 우리 시스템에서 개발한 것이 아닌 외부에서 제공하는 데이터를 이용한 것이다.
• 데이터의 집합 크기를 기준으로 RET와 DET로 나뉜다.
  • Recored Element Type (RET)
    • 데이터가 뭉쳐있는 형태다. 데이터베이스로 예시를 들자면, 여러 필드가 모인 '테이블' 같은 느낌이다.
    • RET 카운팅 방식이란, 이 테이블을 기준으로 데이터를 센다는 것을 의미한다. 만약 RET가 존재하지 않는 특별한 데이터베이스의 경우엔 전체를 하나의 RET로 카운팅한다.
  • Data Element Type (DET)
    • 하나의 필드 단위를 의미한다. 예를 들어, '학생' 테이블이 있을 때 이 테이블 내의 '이름', '성별'이 DE다.
    • DET 카운팅 방식에선, 카운팅 대상은 프로세스의 실행을 통해 유지, 관리되고 비반복적이어야 한다.
      • 예시) 두 개의 테이블이 존재한다. A 테이블에서 사용한 필드가 B 테이블에서 사용한 필드와 같으면 한번만 카운팅한다. 즉, 중복인 필드는 카운팅 하지 않는다.
  • DET 측정
    • 경계로 들어오거나 나가는 식별 가능하고 비반복적인 필드에 대해 각각 하나의 DET로 카운팅 한다. (중복 무시)
    • 경계를 통하지 않는 필드는 카운팅하지 않는다.
    • 시스템에서 필요한, 개발자 목적에 의해, 편의에 의해 만들어진 기능과 데이터는 카운팅 하지 않는다.
    • (왜냐면 기능 점수는 사용자 기능 관점이기 때문에, 시스템이 필요한 기능은 세지 않음)

 

2.4. 트랜잭션 기능 점수

• 트랜잭션은 시스템이 실행하는 행동을 의미한다. 따라서, 기능 또는 프로세스 단위로 복잡도를 측정한다.
• 트랜잭션 기능점수 에선 App이 데이터를 처리하고 사용자에게 제공하는 데이터의 복잡도를 측정한다.
• 크게 세가지 방식이 있다. 외부 입력 트랜잭션, 외부 출력 트랜잭션, 외부 조회 트랜잭션.
  • 외부 입력 트랜잭션 (EI)
    • App 외부의 사용자로부터 내부로 들어오는 데이터/제어정보를 이용해 사용자 요구를 처리하는 트랜잭션
    • 쉽게 말해, 외부에서 App 내부로 들어오는 요청이다.
    • 외부 입력 트랜잭션이 있다면 FTR에 +1을 추가한다.
    • 조건: 유입된 데이터/제어정보가 시스템 행동을 변경해야 하며 최소 하나의 내부논리파일과 연관되어야 한다.
    • 주의: 하나의 EI가 처리되는 동안, 유지되고 조회되는 내부논리파일과 외부연계파일에 대해 각각 하나의 FTR로 카운팅
    • 하나의 외부 입력이 내부논리파일도 바꾸고 외부연계파일도 바꾸면 FTR +2다.
  • 외부 출력 트랜잭션 (EO)
    • App 내부에서 외부로 나가서 사용자의 요구를 처리하는 트랜잭션
    • 쉽게 말해, 내부에서 발생된 데이터가 외부에서 처리된다.
    • 해당 트랜잭션이 존재한다면 EO의 FTR을 +1 카운팅한다. 
    • 조건: 처리 로직이 최소 하나의 연산을 수행해야 하고, 이를 통한, 파생데이터가 생성되어야 한다.
  • 외부 조회 트랜잭션 (EQ)
    • App 내부에서 외부로 나가서 사용자가 요구한 데이터를 조회하는 트랜잭션
    • 해당 트랜잭션이 존재한다면 FTR을 +1 카운팅한다.
    • 어떤 수학 공식/계산이 이루어지지 않으며 파생 데이터도 없이 참조만 해야 한다.
• EI, EQ, EO 트랜잭션은 반드시 어떤 실행 명령 메시지가 존재한다. 
• 에러를 띄우는 메시지 마저 DET+1로 친다.
• 동일한 로직에 대해 여러 방식이 있을 경우에도 로직은 같기 때문에 DET+1이다. 

 

3. 총 계산

• 각 트랜잭션에 대해 FTR과 DET를 카운팅 한 다음, 주어진 테이블로 해당 복잡도를 구한 후 수치화시키면 된다.
• 앞에서 구한 기능점수를 더해 '미조정 기능 점수(UFP)'를 구한다.
• UFP = [ILF+EIF] + [EI+EO+EQ]
• 여기서 구한 UFP는 바로 사용되지 않고, 각 시스템의 특성을 조금 더 잘 살리기 위해 '조정인자'를 사용하여 조정한다.
  
  • 조정인자란, 각 시스템마다 다른 특성을 반영하기 위해 사용하는 인자다.
  • 시스템 유형, 활용방안, 환경 등의 14~15개의 특성을 인자로 둔다.
  • 각각의 특성들에 대한 영향도 점수를 0~5점으로 표시하고, 점수 부여는 '사용자'가 수행한다.
  • 이 점수 값을 총 합해서 최종 영향도를 계산한다.
  • 이 최종 영향도를 이용해서, 총 조정인자 값을 구한다.
    • 조정인자 = (총 영향도의 합 * 0.01) + 0.65

 

총 계산을 정리해보자면 아래와 같다.

1. 미조정인자 구하기: UFP = [EIF+IFL] + [EI+EO+EQ]
2. 조정인자 구하기   : VAR = (총 영향도의 합 * 0.01) + 0.65
3. 최종 기능 점수     : AFP = UFP * VAR

 

출처: https://as-backup.tistory.com/42