기능점수 - freetet

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

소프트웨어 프로젝트를 수행하면서 필요한 대가 산정에 대해서는 한국소프트웨어산업협회가 매년 발행하는 가이드가 있다. 그 이력이 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이 아니고선 해볼 일이 많지는 않다. 물론 소규모의 프로젝트에선 어깨너머로 본 숫자들을 만져볼 기회가 있기는 하지만 개발에만 전념하는 개발자들 사이에선 기회도 그렇고 이런 숫자 만지기를 꺼리는 사람도 꽤 있다. 하지만 숫자를 보면 알 수 있는 것들이 정말 많다. 개발도 중요하지만 잠시 눈을 돌려 내 주변을 돌아보면 어떨까? 그러면 적어본 본만큼의 시야가 넓어질 것이다. 정말이지 내가 어디에 와있고 여기서 무슨 일을 하고 있는지도 모르고 그저 열심히만 하고 있지는 않은지? 하늘을 봐야 별을 딴다. 내 별이 어디에 있는지 한번 생각해볼 일이다. 요즘은 더욱 그렇지 아니한가?

일정 관리

일정 관리는 프로젝트가 납기 내 완료될 수 있도록 보증한다. 범위관리가 무엇에 관한 것이라면 일정 관리는 언제 어떻기에 관한 것이다. 그렇다면 누구나 다 아는 일정은 그 일정일까? 프로젝트에서 일정은 다양한 의미를 내포하는데 역할로 본다면 다음과 같다.

✔️ 프로젝트의 시작과 종료 시점, 상호관계 및 마일스톤의 설정

✔️ 프로젝트 외부에서 발생하는 활동과의 조율

✔️ 프로젝트 내부의 활동 간 연관관계 설정

✔️ 수행 기간 동안 활동별 자원할당과 진행

✔️ 주요 자원 요소들 및 장애 파악

✔️ 위험 요소 파악

그러면 일정도 기준이 있을까? 있다. 일정을 작성할 때는 수행 기간과 우선순위를 따진다. 여기엔 시작 일자와 완료 일자를 기준으로 잡는 방법 두 가지가 있다.

✔️ 시작 일자 기준: 프로젝트 시작을 명시하고 활동 기간과 연관관계에 따라 종료 일자를 도출

✔️ 완료 일자 기준: 프로젝트 종료를 명시하고 활동 기간과 연관관계에 따라 시작 일자를 도출

이렇듯 프로젝트 일정은 복잡해 보일 수 있으나 정해진 프로세스가 있으며 업무 범위를 명확히 하여 프로젝트를 수립하고 통제함을 기본으로 한다. 이를 통해 범위와 원가를 잡을 수 있는데 그 구성엔 활동을 정의하고 순서를 배열하며 각각 자원과 기간을 산정하여 일정을 작성하는 흐름이다.

Critical Path

Critical Path(주요공정)는 임계경로 분석법(CPM:Critical Path Method)으로 불리는 프로젝트 관리계획 및 통제 기법으로 많이 사용된다. 이는 일련의 프로젝트 활동 일정을 짜기 위한 수학적인 알고리즘으로 시작부터 끝까지 프로젝트를 완수하는 데 드는 시간을 측정하고 가장 긴 의존 활동을 식별하여 결정한다. 이 방법은 1956년부터 1958년까지 미국 듀퐁(Dupont)사가 건설계획을 추진하면서 개발하였고 이 시기 즈음하여 미국 GM과 해군이 PERT(Program Evaluation and Review Technique)라는 것을 만들었다. 이것들은 모든 형태의 프로젝트, 예를 들어 건축, 소프트웨어 개발, 제품 개발, 각종 공학 및 연구 프로젝트에 널리 쓰이고 있다.

그래서 흔히 들어본 PERT/CPM이 바로 이것이다. PERT는 계획단계에서 공사 기간 단축이 요구되는 때에 비관치, 낙관치, 실제 가능치를 고려하여 공수를 산정한다. CPM은 최소의 비용 증가로 공사 기간을 단축하려 하는 방법으로 각 작업의 시간당 비용증가율을 비교하여 산정하는데 PERT는 활동 수행 기간 추정에 확률 개념을 반영한다는 측면에서 CPM과 구분된다.

다시 말해 CPM은 프로젝트 계획, 리소스 할당 및 작업 일정 계획에 대한 통찰력을 제공하며 이를 사용해야 할 이유는 몇 가지가 있다.

🚩 향후 계획 개선: 현재 진행상태와 기대치를 비교, 현재 프로젝트의 데이터를 추후 프로젝트 계획에 반영한다.
🚩 효과적 자원관리: PM이 작업 우선순위를 정하는 데 도움이 되고 자원을 적재적소에 배치하는 법을 지원한다.
🚩 업무 지연 방지: 네트워크 다이어그램을 이용하여 프로젝트 종속성을 계획하여 일정을 계획한다.

< Critical Path 예 >

Critical Path는 종속성이 중요한데 이는 활동 중 시작일과 종료일 사이의 관계를 말하여 활동 간 논리적 관계를 이야기한다. 이때 지연과 선행을 염두에 두고 작업을 하여 WBS 활동의 전후 관계를 살피고 네트워크 다이어그램을 작성한 뒤 연관관계를 파악하여 프로젝트 종료일과 여유시간을 찾아 공정을 마련한다.

✔️ 지연(lag)은 작업 종료 후 후행 작업을 기다리는 시간이다

✔️ 선행(lead)은 작업 종료 이전 후행 작업이 시작되어 두 작업이 중첩된 시간을 말한다.

✔️ Critical Path는 여유 시간이 없는 일련의 업무와 작업으로 프로젝트 납기일에 영향을 끼치는 활동들의 집합이다.

공수 산정

산정은 프로젝트팀원에 의해 이뤄져야 하며 실제 업무수행을 통해 시행착오를 거쳐야지만 체득할 수 있는 기술이다. 여기엔 여러 가지 방법들이 있는 대표적으로는 이전 유사한 프로젝트의 경험을 바탕으로 산정하거나 다수의 프로젝트 수행으로 구축된 DB나 방법론을 쓰기도 하고 PERT나 Function Point도 사용한다. 우리나라의 경우에는 한국소프트웨어산업협회에서 소프트웨어 사업 추진 시 SW 개발비 등에 대한 적정 대가를 산정하기 위한 기준으로서 “SW 사업 대가 산정 가이드”를 공표하니 이 자료를 자세히 참고해 보는 것도 업무 진행에 많은 도움을 받을 수 있다.

일정 관리 도구

도구들은 너무도 많아 일일이 나열하기도 뭐하다. 하지만 가장 기본이 되는 두 가지 정도만 챙겨도 도구 사용엔 별다른 문제가 없을 것이다.

🚩마일스톤 : 목표를 달성하기 위해 중간중간 발생하는 주요한 이벤트로 프로젝트 기간 중 주요 달성 및 완료의 표식이며 주요 산출물의 달성일을 말한다. 마일스톤은 할당된 기간이 없고 일정표상에 비어있는 다이아몬드(◇)로 기술하며 프로젝트 상 중요한 일자에 stakeholder와의 의사소통에 중요하게 쓰인다.

🚩간트차트 : 일명 Bar 차트로 진척 보고나 통제용으로 주로 쓰인다. 전체 프로젝트의 시작과 종료 기간을 한눈에 볼 수 있고 모든 활동이 기술되어 있어서 프로젝트 내 진척도에 대한 확인 및 의사소통에 주로 사용된다. 작성은 간단하게는 엑셀과 함께 전문화된 많은 툴이 있어 프로젝트 맞는 것을 골라 적극적으로 사용하는 것이 좋다.

※ 사용하실 겁니까?

도구가 없었을 땐 손으로 그렸지만, 지금은 그럴 필요가 전혀 없다. 다만 도입보다도 중요한 것은 경영층과 관리자층의 의지이다. 막상 도입은 했는데 쳐다보지도 않는다면 아래에선 죽어라 하고 헛일만 하는 것일 뿐. 이럴 바에 개발에라도 더 신경 쓰길 원하는 것이 그들의 마음이다. 현실과 괴리되어 흘러가는 프로젝트는 죽은 것이나 다름없다. 괜스레 사람들 빠져나간다고 뭐라 말고 나부터 돌아보자.

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