[Site Map]  [소프트웨어목차]

 

연관토픽

  1. [상위] 소프트웨어 비용산정
  2. [연관] LOC(Line of Code) 기법

 

개념

  • 사용자 관점에서 사용가 요구하고 사용 인도는 기을 정량적으로 산정하여 소프트웨어 규모를 측정하는 방법(ISO/IEC 14143)
  • 소프트웨어 크기를 결정하는 소프트웨어 기능 유형 별 수량과 성능 및 품질 요인들의 영향도를 고려하여 계산되는 SW 규모 산정 방식
  • 정보처리의 규모와 기능의 복잡도 요인에 의거한SW 규모 산정 방법으로 개발자 중심의 물리적 접근 방식에서 벗어나사용자 관점에서 소프트웨어 규모 측정 모델

 

 

기능 점수 산정 방법

더보기

기능 점수 산정 방법은 1979년 알란 알브레히트가 소개하고 1986년 국제 기능 사용자 그룹(IFOUG)의 발족으로 활성화됨. ISO/IEC 14143으로 소프트웨어 규모에 대한 국제 표준으로 제정되어 소프트웨어 개발, 유지 관리 및 운영을 위한 비용과 자원 소요를 산정하는데 활용

 

 

 

기능점수 등장배경

등장배경

내용

추정의 어려움

소프트웨어 개발 초기에 프로그램LOC를 추정하기 어려움

환경의 영향

동일한 기능을 하는 소프트웨어라도 개발 언어에 따라 소프트웨어 라인 수는 크게 다른 문제 발생

파라메터 영향

기능은 동일하여도 3단계CS 방식, 1단계 CS 방식, 웹 환경 등에 따라 비용 산정의 어려움

 

 

 

기능점수 방식의 특징

특징 설명
기능측정 소프트웨어가 사용자에게 제공하는 기능적 요구사항을 측정
수요자 관점 '사용자가 어떠한 기능을 요구했는지'에 집중하여 측정
사전 측정 가능 실제 개발 이전에 업무량을 측정 가능
활용성 개발은 물론 기획, 운영 등 전 수명주기에 걸쳐서 측정 가능
일관성 조직, 구현 기술, 적용 방법론과 무관하게 측정 가능

 

 

 

기능점수 장점

장점

설명

사용자 요구사항 기반

사용자의 요구사항만으로 기능을 추출하여 측정. 구현 기술, 구현 언어, 개발도구, 개발자의 능력과 상관없이 규모를 일관성 있게 제공

객관적 요구사항만으로 측정

개발방법이나 개발 팀과 무관하므로 소프트웨어 규모 산정에 일관성 제공

모든 개발 단계에서 사용

계획 단계뿐만 아니라 분석, 설계, 구현 단계에서도 사용할 수 있고 단계가 진행됨에 따라 더 정확한 기능 점수 산정 가능

 

 

 

 

기능점수 단점

단점

설명

높은 분석 능력 요구

요구 사항으로부터 기능을 도출하려면 상당한 분석 능력이 요구

FP 전문가 필요

기능 점수를 잘 사용할 수 있는 기능점수 전문가 필요

내부 로직 위주 소프트웨어 부적합

사용자가 알 수 있는 기능으로 측정하기 때문에 내부 로직 위주의 소프트웨어를 측정하는데는 다소 부적합

개발 규모 측정에만 적합

실제 개발 공수를 직접 나타내는 것은 아니기 때문에 개발 규모를 예측하는데만 적합

 

 

 

기능점수 구성

유형

기능

내용

트랜잭션 기능

외부입력(EI)

  • 외부 입력(External Input) (입력 트랜잭션, 입력 화면)
  • 어플리케이션 외부로부터 데이터 또는 제어 정보를 받아 들여, 내부논리 파일의 유지(추가/수정/삭제 등), 어플리케이션의 상태에 변경을 요구하는 단위 프로세스 

외부 출력(EO)

  • 외부 출력(External Output) (출력 트랜잭션, 출력보고서)
  • 어플리케이션 내부에서 데이터 또는 제어 정보를 경계 밖으로 내보낼 것을 요구하는 단위 프로세스 

외부 조회(EQ)

  • External inQuery. 데이터 가공 없는 입출력
  • 어플리케이션 내부에서 데이터 또는 제어 정보를 경계 밖으로 내보낼 것을 요구하는 단위 프로세스 

데이터 기능

내부논리파일(ILF)

  • 측정범위 내에서 유지되는 논리적 데이터 그룹 또는 제어 정보(Control Information)

외부연계파일(EIF)

  • 측정 시스템 참조 데이터 집합
  • 측정범위 밖의 다른 어플리케이션에서 참조하는 논리적 데이터 그룹 또는 제어 정보 단, 다른 어플리케이션에서 내에서 반드시 ILF로 유지

 

 

 

 

기능점수 산정방법

  • SW사업 대가 산정에서 제시하는 기능 점수 산정 방법은 정규법과 간이법 2가지로 구분됨

구분

정규법

간이법

개념

논리적인 설계를 바탕으로 각 기능의 속성을 정의하여 기능별 복잡도 매트릭에 의한 기능점수 산정 방식

개략적 사용자 요구사항 바탕 기능 점수를 도출하여 평균 복잡도에 의한 기능 점수 산정 방식

적용시점

개발요건 및 요건별 상세 설계 정보가 제공되는 시점

일반적으로 설계 공정 이후부터 폐기까지

개발요건만 정의되면 예산수립, 사업발주, 개발, 운영 및 유지보수, 폐기까지 모든 단계에서 적용가능

사용목적

SW 분석/설계, 개발, 유지보수 범위, 일정 및 원가 산정

예산수립, 제안서견적 및 계약SW 사업대가 산정

측정항목

데이터기능 및 DET, RET수 도출

트랜잭션 기능 및DET, FTR 식별

데이터 기능, 트랜잭션 기능

복잡도

기능별 복잡도 매트릭(Low, Average, High)

평균 복잡도

 

 

 

 

산정절차

단계 설명
1. 계산 유형 결정

개발프로젝트, 개선프로젝트, 어플리케이션 비용 산정 등의 유형을 결정

2. 범위 및 경계 식별

SW 사업 범위와 어플리케이션의 ILF, EIF를 구분하여 경계 식별

3. 데이터 기능 계산

ILF EIF를 식별하고, DET/RET을 기반으로 복잡도를 계산하고, 미조정 데이터 기능점수 계산

4. 트랜잭션 기능 계산

외부 입력(EI), 외부 출력(EO), 외부 조회(EQ) 식별

DET/FTR를 기반으로 복잡도를 계산하고 트랜잭션 기능 점수 계산

5. 미조정 FP 계산

데이터기능점수 + 트랜잭션 기능점수

6. 조정 인자 결정

보정계수(언어, 규모, 품질 등 14개 인자로 구성) * 0.01 + 0.65

7. 조정 기능점수 결정  미조정 FP점수 보정계수
  • 개발 초기 제안 단계, 개발 단계에서는 평균 복잡도를 활용한 간이법을 주로 적용하고, 개발 완료 후 비용 정산시에는 정규법을 주로 적용함

 

 

 

기능점수 상세활동

1) 측정유형 결정

종류

내용

개발 프로젝트

(DFP)

  • 처음 설치된 어플리케이션을 통해 사용자에게 제공되는 기능을 측정하는 것으로 프로젝트 개발 동안 계산
  • 초기 어플리케이션 기능점수로 계산되는 기능과 데이터 컨버전을 위해 필요한 기능 포함

유지보수 프로젝트(EFP)

  • 새로운 기능의 추가, 기존 기능의 삭제, 기존 기능의 변경을 포함하여 기존 어플리케이션을 수정하여 사용자에게 제공되는 기능

어플리케이션(AFP)

  • 설치된 어플리케이션이 최종 사용자에게 제공하는 현재 기능
  • 기준 선 또는 설치된 기능점수에 해당
  • () 유지보수규모 산정

 

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

구분

종류

내용

측정범위와 어플리케이션

경계 식별

범위결정

규모 계산 대상 소프트웨어의 하위 구성요소를 정의

기능점수 계산 목적에 따른 필요 기능을 식별

경계식별

내부어플리케이션과 외부 사용자 세계 간의 개념적 인터페이스

어플리케이션에 의해 유지되는 논리데이터를 둘러싸고 있음

  • 어플리케이션 경계는 사용자 관점을 기반으로 구성되기 때문에 사용자가 보는 분리된 기능영역에 기초하는 것으로 기술적 고려사항에 의한 것이 아님

 

3) 데이터 기능 유형(Data Function Type)

구분

종류

내용

데이터 기능

유형 식별

내부 논리 파일(ILF)

측정 대상 어플리케이션 내부에서 유지되며 사용자가 요구한 기능을 수행하기 위해 읽히거나 참조되는 데이터 그룹의 모음(내부DB)

외부 연계 파일(EIF)

측정 대상 어플리케이션 외부에서 유지되며, 사용자가 요구한 기능을 수행하기 위해 잃히거나 참조되는 데이터 그룹(외부DB)

복잡도 및 기여도 결정

레코드요소유형(RET)

ILF또는 EIF 내부에 존재하는 것으로 하나의 정보를 구성하는 DB의 테이블과 같은 관련 데이터 그룹

사용자가 식별 가능한 데이터 요소의 서브 그룹

데이터요소유형(DET)

RET에 존재하는 것으로 RET를 구성하는 개별 데이터 필드

  • RETDET 값이 결정되고 나면 복잡도와 기여도Metric이 정의된 테이블을 참고하여ILFEIF의 값이 산정

 

데이터 기능 복잡도Metric

 

DET

1~19

20~50

>51

RET

1

Low

Low

Average

2~5

Low

Average

High

>5

Average

High

High

 

데이터 기능 기여도Metic

 

복잡도

Low

Average

High

ILF

7

10

15

EIF

5

7

10

  • RET개수와DET 개수를 활용하여 복잡도를 먼저 구하고 기여도 테이블에 따라 기여도를 산출함

 

4) 트랜잭션 기능 유형(Data Function Type)

구분

분류

설명

트랜잭션

기능유형 식별

외부입력(EI)

  • 애플리케이션 경계 안으로 들어오는 데이터나 제어정보를 처리하는 단위 프로세스

외부출력(EO)

  • 애플리케이션 경계 밖으로 조회되는 파생 데이터 생성 같은 처리로직 포함 단위 프로세스
  • 데이터나 제어정보를 어플리케이션 경계 외부의 사용자 또는 다른 어플리케이션으로 내보내어 사용자의 요구를 처리하는 기능

) 가입한 회원의 평균 나이를 계산하는 과정과 같은 처리 로직이 있으며 파생 데이터가 발생

외부조회(EQ)

  • EO와 같으나 파생 데이터 생성과 같은 처리 로직을 포함하지 않는 단위 프로세스(계산 처리 없이 단순 데이터가 외부로 나가는 것)

복잡도 및 기여도 결정

참조 파일유형(FTR)

  • 트랜잭션 기능에 의해 조회/유지되는 ILF 또는 EIF(어플리케이션에서 참조하는 ILF EIF의 수)

데이터 요소유형(DET)

  • 사용자가 식별 가능하고 반복되지 않는 유일한 필드

 

EI기능 복잡도Metric

 

DET

1~4

5~15

> 16

FTR

<2

Low

Low

Average

2

Low

Average

High

>2

Average

High

High

 

EI기여도Metic

 

복잡도

Low

Average

High

EI

3

4

6

 

EO, EQ 복잡도Metic

 

DET

1~5

6~19

> 20

FTR

<2

Low

Low

Average

2 ~ 3

Low

Average

High

> 3

Average

High

High

 

EO, EQ 기여도Metic

 

복잡도

Low

Average

High

EO

4

5

7

EQ

3

4

6

 

 

5) 미조정 기능 점수(UFP, Unadjusted Function Point) 

 

6) 값 조정인자 결정(VAF, Value Adjustment Factor)

  • 측정되어지는 어플리케이션의 일반적 기능에 등급을 부여한14개의 일반 시스템 특성(GSC) 기반을 두고 각 특성은 영향도 정도의 파악할 수 있도록 적용 명세를 가짐
  • 영향도의 범위는 없음(0)에서 강함(5) 까지6등급으로 표시되고 조정 기능 점수는 미조정 기능점수의 ±35 %까지 조정이 가능

 

일반적인 웹 어플리케이션의GSC영향도 및 조정인자는 다음과 같음(IFPUG 기준)

일반적인 시스템 특성

영향도

데이터 통신 (Data Communications)

4 or 5

분산 데이터 처리(Distributed Data Processing) 

3 or 4

성능(Performance)

4 or 5

자원제약 정도(Heavily Used Configuration)

3 ~ 5

트랜잭션 비율(Transaction Rate)

0 ~ 4

온라인 데이터 입력(Online Data Entry)

5

사용자의 효율성(End-User Efficiency)

5

온라인 갱신(Online Update)

3

처리 복잡도(Complex Processing)

플랫폼과 무관

재사용성(Reusability)

플랫폼과 무관

설치 용이성(Installation Ease)

플랫폼과 무관

운영 용이성(Operational Ease)

플랫폼과 무관

다중 설치성((Multiple Sites)

플랫폼과 무관

변경 용이성(Facilitate Change)

플랫폼과 무관

총 영향도

27 ~ 36 + 

조정인자

0.93 ~ 1.01 + 

 

 

국내에서는 한국소프트웨어산업협회의 SW대가산정 가이드에 따라 4가지의 보정계수와 산출 방법을 제시하고 있음

 

규모 보정 계수

  • 규모에 따라 값을 보정해 주는 것으로 일반적으로 규모가 커지면 복잡도가 증가하여 생산성이 떨어질 수 밖에 없기 때문에 규모에 따라 보정 계수를 높여줘야 함
  • 기능점수가 300 미만이면 규모 보정 계수가 0.65이고 그 이상이면 다음 공식을 따름

 

어플리케이션 유형 보정 계수

  • 규모가 같더라도 소프트웨어 유형에 따라 복잡도가 달라 생산성도 달라지는 것을 보정해 주는 것으로 어플리케이션 유형을 8가지로 구분하여 보정 계수 적용

유형

내용

보정계수

업무처리용

인사, 회계, 영업 등 경영 관리 및 업무 처리용 소프트웨어 등

1.0

과학기술용용

과학계산, 시뮬레이션, 스프레드시트, 통계, CAE, OR 등등

1.2

멀티미디어용

그래픽, 영상, 음성 등 멀티미디어 응용 분야, 지리정보, 교육/오락용 등 

1.3

지능 정보용

자연어 처리, 인공지능, 전문가 시스템

1.7

시스템용

운영체제, 언어 처리 프로그램, DBMS, 인간/기계 인터페이스, 윈도우 시스템, CASE, 유틸리티 등

1.7

통신제어용

통신 프로토콜, 에뮬레이션, 교환기 소프트웨어, GPS 

1.9

공정제어용

생산관리, CAM, CIM, 기기제어, 로봇제어, 실시간, 내장형SW 

2.0

지휘통제용용

군•경찰 등의 장비, 인력의 지휘 통제를 요하는 소프트웨어

2.1

 

언어 보정 계수

  • 소프트웨어 개발에 사용되는 언어에 따라 생산성도 달라지므로, 개발 언어에 따른 보정계수를 적용, 사용자가 특정 언어를 사용하여 개발하도록 의뢰하는 경우 보정 계수가 정해짐

언어유형

보정계수

어셈블리어, 기계어, 자연어

1.9

C, C++, Java

1.2

코볼, 포트란, 파스칼

1.0

델파이, HTML, 파워빌더, 비주어베이직, XMLm Script(JSP, ASP, PHP, 플래시 등)

0.8

엑셀, 스프레드 시트

0.6

 

품질/특성 보정계수

  • 개발할 소프트웨어에 대해 사용자가 특정 품질을 요구하는 경우 사용자 요구 품질/특성에 따라 보정 계수 적용

품질/특성요소

설명

보정계수

분산처리

분산 처리에 대한 요구사항이 명시되어 있지 않음

0

클라이언트/서버 및 웹 기반 어플리케이션과 같이 분산처리와 자료 전송이 온라인으로 수행

1

어플리케이션상의 처리 기능이 복수 개의 서버 또는 프로세서에서 동적으로 상호 수행됨

2

성능

성능에 대한 특별한 요구 사항이나 활동이 명시되지 않으며 기본적인 성능이 제공

0

응답시간 또는 처리율이 피크 타임 또는 모든 업무 시간에 중요

연동 시스템의 처리 마감 시간에 대한 제한이 있음

1

성능 요구 사항을 만족하기 위해 설계 단계부터 성능 분석이 요구되거나, 설계/개발/구현 단계에서 성능 분석 도구가 사용

2

신뢰성

신뢰성에 대한 요구 사항이 명시되지 않으며 기본적인 신뢰성이 제공됨

0

고장 시 쉽게 복구할 수 있는 수준으로 약산 불편한 손실이 발생

1

고장 시 복구가 어려우며, 재정적 손실이 많이 발생하거나 인명 피해 위험이 있음

2

다중사이트

설계 단계에서 하나 이상의 설치 사이트에 대한 요구사항이 고려

어플리케이션이 동일한HW/SW 환경 하에서만 운용되도록 설계

0

설계 단계에서 하나 이상의 설치 사이트에 대한 요구사항이 고려

어플리케이션이 유사한HW/SW 환경 하에서만 운용되도록 설계

1

설계 단계에서 하나의 설치 사이트에 대한 요구사항만 고려됨

어플리케이션이 상이한HW/SW 환경 하에서만 운용되도록 설계

2

  • 각 품질/특성 요소에 대한 영향도의 합계에 다음과 같은 산식을 적용하여 보정 계수를 최종적으로 산출

 

조정 기능 점수 결정

  • 최종 조정된 기능 점수인 보정 후 개발 원가는 다음과 같은 공식으로 계산

 

 

 

 

기능점수 방식의 SW 개발비 산정

 

소프트웨어 개발비의 구성요소

  • 기능점수 방식에 의한 소프트웨어 개발비는 크게 소프트웨어 개발원가, 직접경비, 이윤의 세가지로 구성

 

기능점수 방식에 의한 소프트웨어 개발비 산정절차

 

 

 

간이법 vs. 정규법

구분 간이법 정규법
개념 기능 점수 산정 시 기능 유형별 평균 복잡도를 적용하여 기능 점수를 산출하는 방법 기능을 도출하고, 각 기능의 유형별 복잡도 고려하여 정확한 기능점수 산정을 필요로 할 경우 사용되는 일반적 방법
목적 개략적인 기능점수 측정 상세 기능점수 측정
적용시기 예산 수립/제안단계 분석/설계 단계 이후
측정항목

- 데이터 기능

- 트랜잭션 기능

- 데이터 : DET/RET

- 트랜잭션 : DET/FTR

복잡도 - 평균 복잡도 - 기능별 복잡도
장/단점

- SW 규모 측정 신속성, 산출 비용 최소화

- 제한적 데이터 활용

- 정확한 SW 규모 측정 재활용 가능

- 사업초기 적용 어려움

관련기준 - IFPUG 기능점수 측정 매뉴얼(CPM) - SW 사업대가 기준의 평균 복잡도를 반영

 

 

 

FP vs. LOC

구분 Function Point LOC
특징 기능 중심의 산정방법, 사용자 중심 크기 중심의 산정방법, 개발자 중심
규모산정 초기 사업규모 예측가능 개발 50% 이상 지나야 예측가능
장점 기능 고려, LOC 단점 보완 사용 용이
단점 복잡도 산정에 주관이 개입 가능 단순하고, Code 재사용이 무시

 

 

 

전자신문

  1. 200227 '공공 통합유지보수 사업' 이대로 괜찮나

 

 

 

[Top]

+ Recent posts