기능 점수

3. 기능 점수 분석 방법

기능 점수 분석 방법은 1979년 IBM의 앨런 J. 알브레히트가 제안한 ''애플리케이션 개발 생산성 측정''에서 처음 정의되었다.^[4] 이 방법은 소프트웨어의 기능 요구 사항을 출력, 문의, 입력, 내부 파일, 외부 인터페이스의 5가지 유형으로 분류하고, 각 기능의 복잡성을 평가하여 기능 점수를 할당한다. 이러한 기능 점수는 최종 사용자 비즈니스 기능에 쉽게 매핑되지만, 알고리즘과 같이 구현에 리소스가 필요한 내부 기능은 반영하기 어렵다는 단점이 있다.

현재 ISO에서 인정한 기능 점수 측정 방법(FSM) 중에는 알고리즘 복잡성을 고려하는 방법이 없다. 이러한 단점을 보완하기 위해 다양한 접근 방식이 제안되었으며, 알브레히트 기반 IFPUG 방법의 변형은 다음과 같다.

• 초기 및 간편한 기능 점수
• 엔지니어링 기능 점수
• 뱅(Bang) 측정
• 기능 점수
• 가중 마이크로 기능 점수
• 퍼지 기능 점수

3. 1. 기능 유형

• 초기 및 간편한 기능 점수 - 문제 및 데이터 복잡성에 대해 두 가지 질문으로 조정하여 다소 주관적인 복잡성 측정을 얻는다. 데이터 요소 계산을 생략하여 측정 작업을 단순화한다.
• 엔지니어링 기능 점수 - 요소(변수 이름)와 연산자(산술, 같음/다름, 부울 등)를 계산한다. 이 변형은 계산 기능을 강조하며,^[5] 연산자/피연산자 기반의 할스테드 복잡도 측정과 유사하다.
• 뱅(Bang) 측정 - 사용자가 인식하는 "제공되어야 하는 진정한 기능의 척도"인 뱅에 영향을 미치거나 뱅을 보여주는 12개의 기본(단순) 계수를 기반으로 기능 메트릭을 정의한다. 뱅 측정은 소프트웨어 단위가 제공하는 유용한 기능 측면에서 가치를 평가하는 데 도움이 될 수 있지만, 관련 문헌 증거는 거의 없다. 뱅 측정은 운영 시스템 유지 관리 - 개요에서 논의된 것처럼, 재 엔지니어링(전체 또는 부분)을 고려할 때 적용될 수 있다.
• 기능 점수 - 운영 체제, 통신 시스템 등 상당한 내부 처리가 있는 시스템에 대한 적용 가능성을 개선하기 위해 변경 사항을 추가한다. 사용자가 쉽게 인식할 수는 없지만 적절한 작동에 필수적인 기능을 고려할 수 있다.
• 가중 마이크로 기능 점수 - 프로그램 흐름 복잡성, 피연산자 및 연산자 어휘, 객체 사용 및 알고리즘에서 파생된 가중치를 사용하여 기능 점수를 조정하는 최신 모델 중 하나이다(2009년).
• 퍼지 기능 점수 - 낮음 x 중간 및 중간 x 높음 복잡도 간의 퍼지하고 점진적인 전환을 제안한다.^[6]

3. 2. 복잡도 평가

• 초기 및 간편한 기능 점수 - 문제 및 데이터 복잡성에 대해 두 가지 질문으로 조정하여 다소 주관적인 복잡성 측정을 얻는다. 데이터 요소 계산의 필요성을 없애 측정 작업을 단순화한다.
• 엔지니어링 기능 점수 - 요소(변수 이름)와 연산자(예: 산술, 같음/다름, 부울)를 계산한다. 이 변형은 계산 기능을 강조한다.^[5] 그 의도는 연산자/피연산자 기반의 할스테드 복잡도 측정과 유사하다.
• 뱅(Bang) 측정 - 사용자가 인식하는 "제공되어야 하는 진정한 기능의 척도"로 정의되는 뱅에 영향을 미치거나 뱅을 보여주는 12개의 기본(단순) 계수를 기반으로 하는 기능 메트릭을 정의한다. 뱅 측정은 소프트웨어 단위가 제공하는 유용한 기능 측면에서 해당 가치를 평가하는 데 도움이 될 수 있지만, 그러한 적용에 대한 문헌 증거는 거의 없다. 뱅 측정의 사용은 운영 시스템 유지 관리 - 개요에서 논의된 바와 같이, 재 엔지니어링(전체 또는 부분)을 고려할 때 적용될 수 있다.
• 기능 점수 - 상당한 내부 처리가 있는 시스템(예: 운영 체제, 통신 시스템)에 대한 적용 가능성을 개선하기 위해 변경 사항을 추가한다. 이를 통해 사용자가 쉽게 인식할 수 없지만 적절한 작동에 필수적인 기능을 고려할 수 있다.
• 가중 마이크로 기능 점수 - 프로그램 흐름 복잡성, 피연산자 및 연산자 어휘, 객체 사용 및 알고리즘에서 파생된 가중치를 사용하여 기능 점수를 조정하는 최신 모델 중 하나(2009년)이다.
• 퍼지 기능 점수 - 낮은 x 중간 및 중간 x 높은 복잡도 간의 퍼지하고 점진적인 전환을 제안한다.^[6]

4. 기능 점수 계산 과정

IBM의 앨런 J. 알브레히트가 1979년에 발표한 ''애플리케이션 개발 생산성 측정(Measuring Application Development Productivity)''에서 기능 점수가 처음 정의되었다.^[4] 기능 점수는 소프트웨어의 기능 요구 사항을 식별하고, 각 요구 사항을 출력, 문의, 입력, 내부 파일, 외부 인터페이스의 5가지 유형으로 분류한다. 각 기능은 복잡성에 따라 평가되어 기능 점수가 할당된다. 이러한 기능들은 데이터 입력(입력)이나 사용자 쿼리(문의)와 같이 최종 사용자의 비즈니스 기능에 직접 연결된다.

기능 점수는 사용자 중심 요구 사항을 쉽게 반영하지만, 알고리즘과 같이 구현에 많은 자원이 필요한 내부 기능은 제대로 반영하지 못하는 경향이 있다. 현재 ISO에서 인정하는 기능 점수 측정 방법(FSM) 중에는 알고리즘 복잡성을 고려하는 방법이 없다.

이러한 단점을 보완하기 위해 다양한 접근 방식이 제안되었고, 상용 소프트웨어 제품에도 구현되었다. 알브레히트 기반 IFPUG 방법의 변형은 다음과 같다.

• 초기 및 간편 기능 점수: 문제 및 데이터 복잡성에 대한 두 가지 질문으로 조정하여 복잡성을 측정한다. 데이터 요소 계산을 생략하여 측정을 단순화한다.
• 엔지니어링 기능 점수: 요소(변수 이름)와 연산자(예: 산술, 같음/다름, 부울)를 계산하여 계산 기능을 강조한다.^[5] 할스테드 복잡도 측정과 유사하다.
• 뱅(Bang) 측정: 사용자가 인식하는 "제공되어야 하는 진정한 기능의 척도"를 정의하는 12개의 기본 계수를 기반으로 기능 메트릭을 정의한다. 소프트웨어 단위가 제공하는 유용한 기능 측면에서 가치를 평가하는 데 도움이 될 수 있지만, 관련 문헌 증거는 부족하다. 운영 시스템 유지 관리 개요에서 논의된 것처럼 재 엔지니어링(전체 또는 부분)을 고려할 때 적용할 수 있다.
• 기능 점수: 운영 체제, 통신 시스템 등 내부 처리가 많은 시스템에 적용 가능성을 개선하기 위해 변경되었다. 사용자가 쉽게 인식할 수 없지만 작동에 필수적인 기능을 고려한다.
• 가중 마이크로 기능 점수: 프로그램 흐름 복잡성, 피연산자 및 연산자 어휘, 객체 사용, 알고리즘에서 파생된 가중치를 사용하여 기능 점수를 조정하는 최신 모델 중 하나이다(2009년).
• 퍼지 기능 점수: 낮음 x 중간, 중간 x 높음 복잡도 간의 점진적인 전환을 제안한다.^[6]

5. 기능 점수 활용

기능 점수는 코드 라인 수 대신 몇 가지 추가적인 문제를 해결하고자 사용된다.

• 개발자가 더 생산적으로 일하도록 유도하는 경우, 생성된 코드 라인 수의 "팽창" 위험이 있어 측정 시스템의 가치가 감소할 수 있다. 기능 점수 옹호론자들은 이를 문제의 크기가 아닌 솔루션의 크기를 측정하는 것으로 언급한다.
• LOC(코드 라인 수)는 더 높은 수준의 언어와 유사한 양의 기능을 제공하기 위해 더 많은 코드 라인이 필요한 저수준 언어를 보상한다.^[7] C. Jones는 자신의 저서에서 이를 수정하는 방법을 제시한다.^[8]
• LOC 측정은 제공될 코드 라인 수를 추정하기 어려운 초기 프로젝트 단계에서는 유용하지 않다. 그러나 기능 점수는 요구 사항에서 파생될 수 있으므로 프록시 추정(estimation by proxy)과 같은 방법에서 유용하다.

6. 한계 및 비판

기능 점수는 코드 라인 수(LOC) 대신 몇 가지 추가적인 문제를 해결하고자 사용된다.

• 개발자가 더 생산적으로 일하도록 유도하는 경우, 생성된 코드 라인 수의 "팽창" 위험이 있어 측정 시스템의 가치가 감소할 수 있다. 기능 점수 옹호론자들은 이를 문제의 크기가 아닌 솔루션의 크기를 측정하는 것으로 언급한다.
• LOC 측정은 더 높은 수준의 언어와 유사한 양의 기능을 제공하기 위해 더 많은 코드 라인이 필요한 저수준 언어를 보상한다.^[7] C. Jones는 자신의 저서에서 이를 수정하는 방법을 제시한다.^[8]
• LOC 측정은 제공될 코드 라인 수를 추정하기 어려운 초기 프로젝트 단계에서는 유용하지 않다. 그러나 기능 점수는 요구 사항에서 파생될 수 있으므로 프록시 추정(estimation by proxy)과 같은 방법에서 유용하다.

7. 개선된 기능 점수 측정 방법

IBM의 앨런 J. 알브레히트가 1979년에 발표한 ''애플리케이션 개발 생산성 측정(Measuring Application Development Productivity)''에서 기능 점수가 처음 정의되었다.^[4] 초기 기능 점수 측정 방법은 소프트웨어의 기능 요구 사항을 식별하고, 이를 출력, 문의, 입력, 내부 파일, 외부 인터페이스의 5가지 유형으로 분류했다. 각 기능은 복잡성에 따라 평가되어 기능 점수가 할당되었다. 이러한 기능들은 최종 사용자 비즈니스 기능(예: 데이터 입력, 사용자 쿼리)에 쉽게 매핑되었지만, 구현에 필요한 내부 기능(예: 알고리즘)은 고려하지 않는 경향이 있었다.

현재 ISO에서 인정한 기능 점수 측정 방법(FSM) 중에는 알고리즘 복잡성을 고려하는 방법은 없다. 이러한 단점을 보완하기 위해 다음과 같은 다양한 변형된 기능 점수 측정 방법들이 제안되었고, 상용 소프트웨어 제품에도 구현되었다.

• 초기 및 간편 기능 점수: 문제 및 데이터 복잡성에 대한 두 가지 질문을 통해 조정하여 주관적인 복잡성 측정을 제공한다. 데이터 요소 계산을 생략하여 측정을 단순화한다.
• 엔지니어링 기능 점수: 요소(변수 이름)와 연산자(예: 산술, 같음/다름, 부울)를 계산하여 계산 기능을 강조한다.^[5] 이는 할스테드 복잡도 측정과 유사한 접근 방식이다.
• 뱅(Bang) 측정: 사용자가 인식하는 "제공되어야 하는 진정한 기능의 척도"인 뱅을 정의하고, 12개의 기본 계수를 기반으로 기능 메트릭을 계산한다. 뱅 측정은 소프트웨어 단위의 유용한 기능을 평가하는 데 도움을 줄 수 있지만, 실제 적용 사례는 많지 않다. 운영 시스템 유지 관리와 같이 재 엔지니어링을 고려할 때 뱅 측정을 활용할 수 있다.
• 기능 점수: 운영 체제나 통신 시스템과 같이 내부 처리가 많은 시스템에 적용 가능성을 개선하기 위해 변경된 방법이다. 사용자가 쉽게 인식할 수는 없지만 시스템 작동에 필수적인 기능을 고려한다.
• 가중 마이크로 기능 점수: 프로그램 흐름 복잡성, 피연산자 및 연산자 어휘, 객체 사용, 알고리즘에서 파생된 가중치를 사용하여 기능 점수를 조정하는 최신 모델 중 하나이다(2009년).
• 퍼지 기능 점수: 낮음, 중간, 높음 복잡도 간의 점진적인 전환을 제안한다.^[6]

참조

_[1] 웹사이트 Estimating Lessons Learned in Project Management – Traditional http://www.pmhut.com[...] Thomas Cutting 2010-05-28
_[2] 웹사이트 ISO/IEC 14143 https://www.iso.org/[...] International Standards Organization 2007-02-01
_[3] 간행물 Automated Function Points http://www.omg.org/s[...] 2013-02
_[4] 논문 Measuring Application Development Productivity IBM Corporation 1979-10-14
_[5] 웹사이트 Engineering Function Points and Tracking System http://www.stsc.hill[...] Software Technology Support Center 2008-05-14
_[6] 학술지 Fuzzy Modeling for Function Points Analysis 2003-06-01
_[7] 서적 The Economics of Software Quality Addison-Wesley 2012
_[8] 서적 Applied Software Measurement: Assuring Productivity and Quality McGraw-Hill 1996-06
_[9] 논문 Software Function, Source Lines of Code, and Development Effort Estimation – A Software Science Validation 1983
_[10] 학술지 Function point analysis: difficulties and improvements 1988-01
_[11] 학술지 Function point analysis: evaluation of a software cost estimation model 1991
_[12] 논문 Specification-based software sizing: An empirical investigation of function metrics 1993
_[13] 서적 Software sizing and estimating: Mk II FPA (Function Point Analysis) John Wiley & Sons, Inc. New York 1991
_[14] 학술지 An algorithm for sizing software products 1984
_[15] 학술지 A comparison of function point counting techniques 1993
_[16] 논문 Using Test Cases To Size Systems: A Case Study 2012-04
_[17] 웹사이트 Estimating Lessons Learned in Project Management – Traditional http://www.pmhut.com[...] Thomas Cutting 2010-05-28