소프트웨어의 규모 측정
이 글을 읽은 사람이라면 대부분 소프트웨어 개발과 관련있는 분일 것이다. 그렇다면, 개발 프로젝트에서 아래와 같은 추산(Estimate) 작업을 어떻게 하고 있는가?
•고객이 원하는 소프트웨어의 가치(금액)은 얼마인가?
•고객이 원하는 소프트웨어를 개발하기 위하여 적정한 기간과 인력은 얼마인가?
위 질문은 프로젝트를 기획하고 진행하는데 반드시 필요한 추산작업이다. 하지만 소프트웨어 개발은 다른 제조공정과 달리 적정 가치와 적정 투입자원을 산술적으로 책정하기에 너무나 애매한 영역이다. 이는 개발이라는 것은 물질적인 것이 아니라 인간의 지적능력을 사용하여 이루이지는 작업이며, 동일한 결과물을 만들어내는 방법도 무한대의 서로 다른 방법을 사용할 수 있기 때문이다. 즉, 아마도 대부분의 회사에서 위 두가지 추산작업은 경험에 의존하여 대략 산출하는 방식을 사용하고 있을 것이다.
소프트웨어의 가치와 소프트웨어 개발에 소요되는 자원을 객관적으로 산출하기 위해서는 소프트웨어의 규모를 정량적으로 표현할 수 있어야 한다. 그리고 그 규모는 명확한 근거에 의하여 서로 다른 사람이 산출해도 거의 동일한 결과를 나타낼 수 있어야 한다.
즉, 기본적으로 제품의 가치와 제품생산에 소요되는 자원의 양은 제품의 크기(규모)에 비례한다고 볼 수 있으므로 소프트웨어의 가치와 투입자원도 이에 따라 소프트웨어의 규모에 의하여 결정하게 되는데, 이 “소프트웨어의 규모”를 정략적으로 측정하는 방식은 시대에 따라 달라져왔다.
•LOC(Line Of Code) : 소프트웨어의 소스코드 라인 수를 측정
•본수 : 소프트웨어의 독립된 기능(물리적기능)의 수를 측정
•M/M(Man Month) : 소프트웨어 개발에 투입되는 인원을 측정
•기능점수 : 소프트웨어의 요구사항(논리적기능)의 규모를 측정
LOC 방식은 현재는 거의 사용되지 않는다. 소프트웨어 규모를 소스코드의 Line 수로 판단할 수 없기 때문이다. (개발을 못하면 규모/가치가 커지는 현상이 발생한다.) 본수개념도 현재는 거의 사용되지 않는다. LOC와 본수는 기본적으로 구현과정이 마친 후에 산출 가능하므로(물리적인 소스에 의존) 프로젝트 기획단계에서의 예산작업 또는 투입자원 산출 시에 적용하기 힘들다. (1990년대 중반만 해도 거의 LOC와 본수로 측정하였다.)
M/M 방식은 아직도 많이 사용중이다. 많은 관공서에서 공공프로젝트 발주시, 투입인력을 최우선시하고, 인건비를 기준으로 프로젝트 예산을 산출한다. (물론 법적으로 기능점수를 권고하고 있지만, 아직은 확실히 정착되지 않고 있다.) 심지어, 기능점수 방식의 소프트웨어 가격근거를 부르짖는 SI 업체조차도 내부적으로 개발자의 성과나 업무량을 근무시간(M/M, 야근을 권장하는)으로 평가한다.
하지만 이 또한 LOC와 마찬가지의 문제를 가진다. 소프트웨어의 규모를 소스코드 Line 수로 판단할 수 없듯이, 개발자의 일한 시간으로 측정하는 것도 불가능하다. LOC와 마찬가지로 일을 못하면 시간이 늘어나기 때문이다.) 또한, LOC/본수/MM 모두 측정자의 관점에 따라 측정치가 천차만별 다르게 나올 수 있다. 즉, 객관적인 측정자료가 되기 힘든 문제가 있다.
기능점수의 출현
많은 S/W 개발회사가 위와 같은 문제로 소프트웨어의 규모를 측정하지 못하여 많은 실패를 하였다. IBM도 예외는 아니었다. IBM은 이러한 실패를 줄이기 위하여 1960년대 소프트웨어 개발 프로젝트에 대해 보다 정확한 예측(규모측정)을 하기 위한 노력을 기울였고, 그 결과 1969년 소프트웨어의 비용산정기법과 도구를 개발하였다. 이 기법은 “업무적 요소”와 “기술적 요소”를 분리하여 규모를 측정하여여 객관적인 측정을 가능하도록 하였다.
1970년대 후반, 보다 객관적인 규모의 측정을 위하여 소프트웨어의 기능을 개발자의 기술과 무관하게 “사용자의 업무적 기능”을 논리적으로 분석하여 점수화하는 방법이 고안되었는데 이것을 “기능점수 분석법”이라고 한다. 소프트웨어 기능을 개발기술과 무관하게 “업무관점에서의 기능 (즉, 고객요구사항)”만으로 측정하는 방식은 “객관적인 규모의 측정”면에서 매우 합리적이다. 기존 규모측정방식의 문제점인 “측정자에 따라 달라지는 규모”문제가 대부분 해결될 수 있기 때문이다. 쉽게 말하자면, “고객의 요구사항이 10개”이면, 개발자가 어떠한 방식으로 개발하더라도 규모는 “10개”로 측정되는 것이다.
이것이 기능점수의 핵심이다. 필자의 경험으로는, 잘못 측정되는 대부분의 기능점수는 바로 “업무기능”을 측정하지 않고 “물리적기능(구현된기능)”을 기준으로 규모를 측정하는 것이다. 이는 대부분의 기능점수가 개발자에의하여 측정되기 때문에 본인의 관점에서 기능을 정의하기 때문일 것이다. 기능점수는 “물리적기능”을 측정하는 것이 아니라 “요구사항”의 규모를 측정하는 방식이다. 이것만 기억하면 기능점수 산출은 쉽다.
이후 기능점수 방식은 지속적으로 개선되어 국제기능점수사용자그룹(IFPUG)에 의하여 표준화되었고, 현재 국제 표준으로 채택되었다.
국내에서의 기능점수 활용
최근 국내에서도 소프트웨어의 제값을 받기 위한 노력이 많이 진행되었다. 국내에서도 2000년대 중반 기능점수가 도입되어 발표되었고, 현재 소프트웨어 견적, 예산의 기준으로 사용되고 있다. 현재 정부에서는 모든 공공사업의 가격근거로 기능점수를 제시하기를 권고하고 있다. 즉, 이제는 국내에서도 소프트웨어의 예산작업, 견적 등에 필수적으로 사용되고 있으므로, 반드시 기능점수의 측정법을 익혀야 하는 상황이 되었다.
내가 근무하는 회사는 주로 공공사업을 대상으로 개발을 하고 있다. 현재 관공서는 기능점수에 근거한 가격산출이 없으면 발주를 낼 수가 없다. 물론 이것이 소프트웨어를 철저히 객관적으로 가치를 산정하여 예산에 반영한다는 의미는 아니다. 아직도 대부분 미리 정해진 예산에 기능점수를 거꾸로 맞추는 식으로 진행되고 있지만, 지속적으로 개선될 것이라고 본다.
기능점수의 활용
기능점수는 소프트웨어의 규모를 객관적으로 측정하는 방식이므로 다양한 분야에 활용될 수 있다. 현재 국내에서는 주로 예산/견적 작업에 활용되고 있지만, 사실 프로젝트 관리 측면에서의 활용도도 상당히 높으며, 사실상 소프트웨어 개발 프로세스의 전영역에서 활용될 수 있다.
1. 소프트웨어 예산/견적 산출
- 가장 많이 사용되는 분야이다. 현재 많은 SI 사업에서 가격산출 근거로 제시되고 있다.
- SI 사업에서 RFP(제안요청서)에 제시된 요구에 대한 적정 가격이란 것은 산출하기 쉽지 않다. 기능점수를 사용하면, 이러한 가격산출을 보다 객관적으로 할 수 있게 한다.
- 또한, 정량적인 규모의 측정은 미리 소프트웨어 개발에 소요되는 원가를 예측할 수 있도록 한다.
물 론, 아직은 국내 현실은 이러한 가격근거에 의하여 예산을 책정하고 있지는 않다. 예산은 대부문 미리 결정되어 진다. 아직은 발주처나 수행처 모두 기능점수에 대한 이해가 부족하여 정확한 가격근거를 산출하지 못하고 소프트웨어의 제값을 책정하는 문화가 정착되지 않고 있다. 예를 들어, “특급기술자” 1MM 투입시 인건비는 월 700-800만원으로 책정되지만, 기능점수에 의거하여 화면 하나를 개발하는 가격을 산출하면 거의 1500만원 선이다.
2. 프로젝트 관리
서두에 말했듯이, 프로젝트의 계획수립을 위하여 투입자원계획과 일정계획은 필수적이다. 기능점수는 “개발규모”에 의거한 계획수립을 가능하게 한다.
즉, 객관적인 규모를 측정하고, 측정된 규모를 개발하기 위해서는 인력이 몇 명 필요한지를 예측할 수 있다. 이는 데이터가 누적될수록 정확해진다. (초기에는 오차가 많겠지만, 데이터가 누적되면, 개발자 1명당 몇점의 규모를 개발가능한지에 대한 통계치가 산출된다.)
즉, 이는 투입자원과 개발기간을 미리 예측할 수 있도록 한다.
3. 개발 관리
기능점수 측정은 Agile의 프로젝트 추정과 계획기법과 매우 유사하다.
Agile에서 추정은 “User Story (요구사항)”에 대한 포인트를 계산하여 규모를 추정하고 이에 따라 자원을 할당한다. 그리고 진척도를 포인트의 완료에 대하여 번다운 차트로 표현한다.
기능점수는 사용자의 요구사항에 대한 측정이므로 User Story와 유사하며, 그 규모를 점수로 측정하는데 이는 User Story의 포인트 측정과 유사하다.
즉, 기능점수를 개발시 활용하면, Agile의 기법을 그대로 적용가능하다.
4. 개발 프로세스 관리
2번과 3번에서 말한바와 같이 기능점수는 개발회사의 각 프로세스에서 유용하게 활용될 수 있다.
이외에도 기존에 소프트웨어의 규모를 측정할 수 있는 객관적인 단위가 없기 때문에 개발조직의 개개인 또는 팀 등의 성과를 측정하기도 힘든데, 이러한 부분에도 기능점수를 활용할 수 있다.
즉, 개발활동에서의 모든 측정단위를 기능점수로 통합할 수 있으며, 이러한 단위의 통합으로 인하여 모든 개발활동의 양을 동일한 단위로 측정하여 활용할 수 있다.
나의 사내 주요 직책 중 하나는 사내 프로세스 개선업무이다. 현재 회사는 표준 개발 프로세스로 기능점수에 의한 진척도 측정법을 표준으로 사용한다. 즉, 기능이 정의 되는 분석단계 말에 도출된 기능에 대한 기능점수를 측정하고, 이에 따라 개발주기계획을 수립한다. 그리고 이 계획에 따른 진척도를 보고하고, 최종적으로 각 개발자와 소속팀의 기여도를 평가한다.
또한 사내 표준 개발방법론에 이를 모두 통합하여 사용하며, 모든 활동의 단위는 “기능(Function or Process)과 기능점수”이다.
즉, 예산수립, 원가측정, 계획수립, 개발진행, 산출물, 평가/성과 등의 모든 측정 기준은 기능점수로 통합되어 있다. 이렇게 하는 경우 돈-사람-일을 모두 일치 시킬 수 있다.
기능점수의 장단점
1. 장점
개발언어, 개발기술과 관계없이 어플리케이션의 복잡도(규모) 계산에 일관성을 제공한다.
(요구사항만으로 측정하므로 실제 구현 방법과 관계가 없다)
조직에 관계없이 규모측정에 일관성을 제공한다.
(객관적인 요구사항만으로 측정하므로 구지 개발팀에서 측정할 필요도 없고, 개발방법과 무관하므로 측정하는 조직과 관계 없이 측정된다.)
소프트웨어 개발 사이클 초기에 이용할 수 있다.
(요구사항만 도출되어 있다면 언제든지 측정가능하므로 초기 예측/추산에 사용될 수 있다.)
개발의 모든 사이클에 기준으로 사용가능하다.
2. 단점
요구사항으로부터 기능을 도출하기 위하여 상당한 분석 능력을 요구한다. 즉, 기능점수를 위한 기능도출의 난이도가 높을 수 있다. 이는 사실 소프트웨어 개발 사이클의 분석단계와 유사한 과정을 요구한다.
기능점수는 사용자가 인지가능한 기능을 측정한다. 따라서 내부로직위주(서버프로세스같은)의 소프트웨어는 측정이 다소 부적합하다.
소프트웨어 대가기준의 표준으로 지정되어 있지만, 아직은 개발자 이외의 집단의 이해도가 낮은 관계로, 원래 취지로 사용되기 힘들다.