Function Point

소프트웨어 규모 산정 – 기능점수 (프로젝트 성공률 1% 높이기)

로

소프트웨어 규모 산정

컴퓨터를 기반한 시스템을 구축하면서 가장 비용이 많이 든 요소는 다름이 아니라 소프트웨어이다. 그래서 소프트웨어의 규모를 알아내는 일이 매우 중요하며 그 역사도 매우 깊다. 이러한 소프트웨어 비용은 사람, 기술, 환경 및 이를 둘러싼 정치, 정책이란 여러 변수의 영향을 많이 받는다. 
 
그래서 소프트웨어 비용의 신뢰성을 높이고 그 노력을 추정하기 위해 많은 방법이 있었다. 프로젝트가 끝날 때까지 추정을 미뤄보기도 하고 소프트웨어 공학을 활용하여 활동들을 분해하여 분석하기도 했으며 과거의 경험과 데이터를 바탕으로 추정하고 도구를 사용하기도 했다.
 
특히 개발 프로젝트의 대상인 소프트웨어의 범위를 양적인 크기와 질적인 수준으로 측정하여 규모를 파악함으로써 소요 공수, 투입자원 및 소요 기간을 파악하여 실행할 수 있는 계획을 수립하기 위해 규모를 산정한다. 이를 통해 투입인력 개개인의 생산성을 측정할 수 있으며 원가를 파악하여 비가시적인 소프트웨어 개발에 대한 최소한의 재무적 성과를 구축할 수 있다. 또한 조직의 실효성 있는 경영계획과 정책 수립에 크게 이바지를 할 수 있다.
 
앞선 글에서도 언급했었지만 소프트웨어 규모를 산정하는 방법은 다양하다. 양적 규모를 산정하는 방법에는 LOC(Line Of Code) 방식, Putnam(생명주기 예측) 모델 및 CoCoMo(Constructive Cost Model) 등이 있고 질적 규모를 산정하는 방법에는 Function Point, McCabe 회전 복잡도, Halstead 소프트웨어과학 등이 있다. 과거에는 소프트웨어도 단순하고 규모가 크지 않아 양적 규모 산정 방법만으로도 충분했으나 근래에는 소프트웨어의 복잡도도 증가하고 그 규모도 너무나 커져서 질적 규모 산정 방법으로 접근하며 그중에서 Fuction Point를 많이 사용하는 추세이다.
 
 

기능점수방식(Function Point)

Fuction Point는 사용자 관점에서의 소프트웨어 개발 규모를 측정하기 위한 표준 ISO/IEC 14143(FSM: Functional Size Measurement)기법으로서 사용자가 요구하여 받는 기능들을 측정하고 구현 기술과 무관하게 소프트웨어 개발 및 유지보수의 규모를 산정할 수 있다. 여기서 기능점수란 사용자 관점에서의 측정된 소프트웨어 기능의 양을 말하며 소프트웨어 기능은 논리적 의미에 따라 데이터와 트랜잭션으로 크게 나눠 볼 수 있다.
 
기능점수방식에서도 크게 일반적인 기능점수 산정 방법(정통 법)과 평균 복잡도를 적용하는 방법(간이 법)의 두 가지가 있으며 정통 법은 소프트웨어 기능을 도출, 각 기능의 유형별 복잡도를 고려하는 일반적인 방법으로 소프트웨어 개발 설계공정 후에 보통 사용되며, 간이 법은 기능의 복잡도를 판단하기 어려운 경우에 적용하며 계산 절차는 정통법과 동일하나 기능점수를 기능 유형별 평균 복잡도를 적용하여 산출한다. 이는 보통 기획 및 발주단계에서 사용된다.

 

비용과 노력 추정 매트릭스

< 비용과 노력 추정 매트릭스 >

기능점수방식은 기능을 중심으로 하는 소프트웨어와 개발과정에 대한 간접척도를 다루며 프로젝트 완료 후 생산성 평가목적으로 개발되었으나 사전 예측 모델로도 이용되고 있다. 이를 좀 더 살펴보면 생산성은 FP/노력으로 볼 수 있으며 품질은 오류 발생률(오류 수/FP)로 측정할 수 있다. 결함 수를 FP로 나누면 결함 발생률이며 비용효율성(=비용/FP) 및 문서화를 위한 측정도 가능하다.
 
이런 기능점수방식은 프로그래밍 언어와 독립적이어서 환경에 영향을 받지 않는 큰 장점이 있다. 하지만 보다시피 이를 잘 활용하기 위해서 숙련된 기술이 필요하고 주관적인 자료들도 많고 수집도 어려운 점이 있다. 특히 사용자 관점에서 이뤄지다 보니 감춰진 측정항목들이 있으며 사용되고 있는 파일 수를 정확히 파악하기가 어렵다.
 
아래는 기능점수에서 사용하는 5가지 측정 항목이다.
 

기능점수 5가지 측정 항목

 
EI(External Input)는 외부 입력측정(사용자 입력 개수), EO(External Output)는 외부 출력측정(사용자 출력 개수), EQ(External inQuery)는 외부 조회측정(사용자 질의 개수)이다. ILF(Internal Logical File)은 내부파일 개수, EIF(External Interface File)는 외부 인터페이스 개수이다.
 




계산 방법

🚩 단계1 : FP 테이블에 따른 기능 수 계산
기능유형                      Count  |  단순  |  보통  |  복잡  |  기능수(FC)
외부 입력:                       [ ]*        3         4         6         = [  ]
외부 출력:                       [ ]*        4         5         7         = [  ]
외부 조회:                       [ ]*        3         4         6         = [  ]
내부 논리파일:                 [ ]*        7        10       15         = [  ]
외부 인터페이스 파일:       [ ]*        5          7       10         = [  ]
 
🚩 단계2 : 복잡도 조정값 계산
14개 기술적 복잡도 요소에 영향도(0 ~ 5의 정수 표시)를 평가하여 합산하여 계산한다. 총영향도(0~70)는 항목(14개)에 영향도(0~5)를 곱하며 기술적 복잡도(TCF)는 0.65 +0.01 * 총영향도로 나타낼 수 있다. 여기서 14개 요소에는 통신, 분산처리, 시스템성능, 사용 빈도, 트랜잭션 비율, 온라인 요구, 온라인복잡도, 파일갱신, 재사용성, 처리 복잡성, 유지보수성, 회복성, 이식성, 분산성이 있다.
 
🚩 단계3 : FP 계산
기능점수(FP)를 계산하며 FC (기능 수)에 TCF (기술적 복잡도)를 곱한다.
 
🚩 단계4 : 경험 데이터 이용 프로젝트 비용과 개발 노력 추정
전체적인 프로젝트 비용은 FP에 FP 당 비용(경험치)을 곱하며, 개발 노력은 FP를 생산성(경험치)으로 나눠 측정한다.
 
 
 
 
※ 직접 해봐야 안다.
쉽지는 않다. 과거의 유사 사례 경험, 양식들이 있다면 우선은 먼저 자료를 구해서 진행하고 있는 프로젝트에 적용해 보길 바란다. 쉬운 방식으로 몇 번 하다 보면 얼추 감이 온다. 그러면서 다른 산정 방법도 같이 하여 서로 값을 비교해보는 것도 좋다. 자주 해보고 나만의 경험을 쌓고 데이터를 쌓아가면서 공부를 해봐야 한다.

대가 산정 (프로젝트 성공률 1% 높이기)

로

소프트웨어 프로젝트 대가 산정

소프트웨어 프로젝트를 수행하면서 필요한 대가 산정에 대해서는 한국소프트웨어산업협회가 매년 발행하는 가이드가 있다. 그 이력이 2012년부터 공식적인 가이드가 제정, 공표되었으니 햇수로 벌써 20년을 훌쩍 넘어서고 있다. 일각에선 현장과 맞지 않는 비현실적 대가라고 말하기도 하지만 이러한 기준이 있기에 그간의 사업 진행도 어떻게든 진행이 되지 않았나 싶다.
 
그러면서 지나온 세월만큼 많은 논의와 고민의 흔적들을 보면서 이 또한 받아들이고 응용해 나아가는 지혜가 필요하지 않나 싶다. 이 가이드는 국가·지방자치단체·국가 또는 지방자치단체가 투자하거나 출연한 법인 또는 기타 공공단체 등(이하 “국가기관 등”이라 한다)에서 소프트웨어의 기획, 구현, 운영 등 수명주기 전체 단계에 대한 사업을 추진하면서 이에 대한 예산 수립, 사업 발주, 계약 시 적정 대가를 산정하기 위한 기준을 제공하는 것을 목적으로 하고 있다.
 
대가 산정 활동은 소프트웨어 프로젝트/사업 전체 생명주기 동안 반복적으로 수행되는 활동으로 발주자나 수주자를 비롯한 다양한 이해관계자들에게 큰 영향을 미치는 중요한 활동이다. 이 가이드를 통하여 사업의 합리적이고 객관적인 대가 산정을 유도하여 프로젝트의 품질을 향상하고 제값 주기 환경을 지속 정착시켜 유관 산업 전반의 경쟁력을 높이는 효과를 거두고자 기대하고 있다.
 
 

대가 산정 가이드 구성

본 대가 산정 가이드는 국가기관 등에서 발주하는 사업에 적용되고 공공부문 사업에 참여하는 공급자도 이를 준용할 수 있도록 개발되었다고는 하나 꼭 이 대상들에만 적용된다고 볼 수는 없으며 그 적용 및 활용 범위는 더 넓다고 할 수 있다. 즉, 이 기준에 따라 각자의 영역과 내용에 따라 이 가이드를 충분히 반영해볼 수 있는 여지가 있는 것이다. 
 
가이드는 또 사용자중심의 활용성을 고려하고 있고 프로젝트 생명주기를 따라 프로젝트관리에서 다루고 있는 기획, 구현, 운영 단계로 크게 체계구성을 하고 있다. 다시 말하면 단순히 구현 단계에서의 대가뿐만 아니라 프로젝트 기획 단계부터 운영 및 데이터베이스 구축 프로젝트에서도 적용해 볼 수 있는 내용을 다루고 있다. 이를 통해 사용자의 주요 업무단계에 따라 대가 산정에서 절차별로 설명하고 있는 것을 참고하여 현장에서의 실무 적용이 용이하도록 하고 있고 표준화하였기 때문에 PM을 포함한 프로젝트 이해관계자들도 이를 좀 더 면밀하게 살피고 공부해야 할 만한 이유가 있다.
 
대가 산정에 대한 방법은 가이드에서 다음의 구성으로 되어 있다.
 
✔️ 대가 산정 방식별 개요
✔️ 절차별 주요 내용
✔️ 단계별 설명
✔️ 주요 산출물
✔️ 관련 법령/규정 등 참고자료 및 유의 사항
✔️ 프로젝트 대가 산정 방식별 사례
 
 

대가 산정 가이드 적용 범위

본 대가 산정 가이드에서는 다양한 대가 산정 모형을 가지고 있다. 이러한 모형들은 하나에 국한되어 있지 않고 그 대상이 되는 사업의 유형과 종류, 시점에 따라 적절한 모형을 선택하여 적용하도록 하고 있다. 이에 따른 사업유형의 식별은 다음과 같다.
 
프로젝트 생명주기와 사업유형

< 프로젝트 생명주기와 사업유형 >

 
 
🚩 기획 단계
: 프로젝트 생명주기 상 기획 단계에 해당하는 사업으로 IT 컨설팅 사업(정보전략계획(ISP), 정보전략계획 및 업무재설계(ISP/BPR), 전사적 아키텍처(EA/ITA), 정보시스템 마스터플랜(ISMP), 정보보안 컨설팅 등)이 있다.
🚩 구현단계
: 프로젝트 생명주기 상 구현단계에 해당하는 사업으로 소프트웨어 개발 사업이 해당한다.
🚩 운영단계
: 프로젝트 생명주기 상 운영단계에 해당하는 사업으로 소프트웨어 유지관리, 소프트웨어 운영 및 소프트웨어 재개발 사업 등이 있다.
 
다음이 대가 산정 시점이다. 이는 대가를 산정하는 시점에 따라 가용한 정보의 양과 상세 정도가 달라지므로 해당 시점에 적합한 대가 산정 모형을 선택하여 사용해야 한다. 
🚩 예산확보 단계
: 프로젝트의 예산을 확보하기 위해 사업비를 개괄적으로 산정하는 단계
🚩 사업발주 단계
: 프로젝트를 발주하기 위해 제안요청서 등을 작성하고 발주금액을 산정하는 단계
🚩 사후정산 단계
: 프로젝트가 종료된 후 사전 산정된 사업비와 집행된 사업비의 차이를 파악하여 필요시 정산을 위한 대가를 산정하는 단계
 
 
그럼 이 대가 산정 모형들에 무엇이 있을까? 그리고 각각의 적용 시점은 어떻게 될까? 아마도 구현단계에 집중된 방식을 많이 접하겠지만 이외의 단계에서도 세부 과정에 따른 산정 방법들이 존재한다.
 
♾️ 기획 단계
   – 정보전략계획(ISP) 및 업무재설계(BPR): (업무량/투입공수) 수립비
   – 전사적 아키텍처(EA/ITA): 수립비
   – 정보시스템 마스터플랜(ISMP): 수립비
 
♾️ 구현단계
   – 소프트웨어 개발: 기능점수방식(정통법/간이법)
 
♾️ 운영단계
   – 유지관리 및 운영: 유지관리비, 운영비(투입공수, 고정비/변동비방식)
   – 재개발: 재개발비
 
 

 

기능점수방식(Function Point)

프로젝트 구현단계에서 주로 쓰이는 기능점수방식은 과거 소스 코드 라인을 카운팅하거나 인력수를 가늠하는 방식들에서 점차 발전하여 현재에 이르렀다. 이는 소프트웨어 개발 규모를 기능점수로 측정하고 기능점수당 단가를 적용하여 비용을 산출한다. 다만 모든 것에 적용할 수는 없는 특별한 경우에는 해당 사업의 과업 내용이나 특징 등을 고려하여 발주자의 판단에 의해 투입공수에 의한 방식도 적용할 수 있다.
 
➰ 기능점수방식 산정: (기능점수 X 기능점수 단가 X 보정계수) + 직접경비 + 이윤
➰ 투입공수방식 산정: (투입인력수 X 투입 기간 X 기술자직무별 단가) + 제경비 + 기술료 + 직접경비
 
기능점수방식은 사용자 관점에서의 사용자가 요구하고 사용자에게 인도되는 기능을 정량적으로 산정하는 소프트웨어 규모 측정 방법으로 ISO/IEC 14143(FSM; Functional Size Measurement)으로 SW Size에 대한 국제표준이며, 소프트웨어 개발, 유지관리 및 운영을 위한 비용과 자원 소요를 산정하는 데 가장 중요한 요소이다.
 
 
기능점수란 사용자 관점에서 측정된 소프트웨어 기능의 양으로서, 사용자에게 제공되는 소프트웨어 기능의 규모를 측정하는 단위이다. 소프트웨어 기능은 사용자 관점에서 갖는 논리적 의미에 따라 크게 데이터 측면의 기능과 트랜잭션 측면의 기능으로 구분된다. 이들을 다시 세분하면 데이터 기능에는 내부 논리파일(ILF)과 외부 연계 파일(EIF)의 2가지 유형이 있으며, 트랜잭션 기능에는 세부적으로 외부 입력(EI), 외부 출력(EO), 외부 조회(EQ)의 3가지 유형이 있다.
 
기능점수방식의 산정 방법은 일반적인 기능점수 산정 방법(정통법)과 평균 복잡도를 적용하는 방법(간이법)의 두 가지이다.
 
✅ 정통법
: 소프트웨어 기능을 도출하고, 각 기능의 유형별 복잡도를 고려, 정확한 기능점수 산정을 필요로 할 경우 사용되는 일반적인 방법으로 통상적으로 소프트웨어 개발 공정상 설계공정 후 사용된다.
✅ 간이법
: 기능의 복잡도를 판단하기 어려운 경우 적용하는 방법으로 계산 절차는 정통법과 동일하나 기능점수 산정 시 기능 유형별 평균 복잡도를 적용하여 기능점수를 산출한다. 통상적으로 기획 및 발주단계에서의 기능점수 측정에 사용된다.
 
 
 
 
※ 숫자가 중요하다
사실 대가 산정은 PM이 아니고선 해볼 일이 많지는 않다. 물론 소규모의 프로젝트에선 어깨너머로 본 숫자들을 만져볼 기회가 있기는 하지만 개발에만 전념하는 개발자들 사이에선 기회도 그렇고 이런 숫자 만지기를 꺼리는 사람도 꽤 있다. 하지만 숫자를 보면 알 수 있는 것들이 정말 많다. 개발도 중요하지만 잠시 눈을 돌려 내 주변을 돌아보면 어떨까? 그러면 적어본 본만큼의 시야가 넓어질 것이다. 정말이지 내가 어디에 와있고 여기서 무슨 일을 하고 있는지도 모르고 그저 열심히만 하고 있지는 않은지? 하늘을 봐야 별을 딴다. 내 별이 어디에 있는지 한번 생각해볼 일이다. 요즘은 더욱 그렇지 아니한가?