실제 기능점수를 예산단계에서 산출하면, 도출하기에 매우 애매한 상황이 많다. 사실 개발비를 되도록 많이 책정해야 하는 기업입장에서는 많은 기능을 도출하여 개발비를 늘려야 하는 입장이지만, 기능점수의 개념이 요구사항의 복잡도를 측정하는 방식이므로, 요구사항이 명확하지 않은 예산수립단계에서는 많은 기능을 제대로 도출하기가 쉽지 않다. 또한 기능점수는 사용자에게 의미있는 기능을 도출하는 방식이기 때문에 개발비를 많이 받아야 하는 서버용 프로그램이나 내부로직위주의 제어 프로세스는 오히려 금액이 책정되지 않는 문제가 발생한다. 또한 대부분의 영업 또는 제안단계에서는 이미 예산이 확정되어 있어서, 기능점수에 의한 개발비를 확정되어 있는 금액에 맞추어야 하는 상황이 많이 발생한다.
?
최근 공공기관에서 발주하는 프로젝트는 전문기관에 기능점수의 검증을 의뢰하는 경우가 늘고 있다. 이런 경우, 검증기관에서 기능점수의 도출 근거 자료를 제시하도록 요구하거나, 잘못 산정된 기능점수의 경우, 기능을 제거하여 개발비가 줄어드는 결과를 가져올 수도 있다.
?
따라서, 기능점수를 실전에 사용할 경우, 산출에 대한 경험도 많이 필요하고, 상황에 따른 산출 요령도 어느정도 필요하다. 이러한 상황별 요령 및 기능점수 검증을 통과하기 위한 팁들을 소개한다.
?
- 기능점수 검증기관은 “점수”를 검증한다. “기능”은 검증할 수 없다.
-?????? 기능점수를 검증하는 기관은 기능점수를 도출한 프로젝트의 업무를 모른다.
-?????? 즉, 기능이 제대로 도출되었는가를 판단할 수는 없다.
-?????? 기능의 검증은 주로 “기능명의 형태”와 기능의 유형의 일치에 집중된다.
-?????? 따라서, 기능의 명칭과 기능의 유형(EI/EO/EQ)가 일치하면 기능의 검증은 대부분 통과된다.
- 기능의 명칭은 CRUD 성 동사를 사용하라
-?????? 위에서 설명한 바와 같이 검증기관은 명칭과 유형의 일치성을 본다.
-?????? 즉, 기능의 명칭을 기능유형이 명확하게 파악되는 이름을 사용한다.
-?????? 즉, “관리”, “입력”, “수정”, “삭제”, “조회”, “검색”등과 같이 CRUD가 명확한 이름을 사용한다.
-?????? 이와 같은 이름은? EI, EO, EQ를 명확하게 한다.
- 내부처리 기능인 경우, 사용자에게 의미있을 것 같은 이름으로 바꾸어라
-?????? 서버 프로그램 또는 백그라운드처리 등의 기능은 사실 기능점수에 도출되지 않는다. 기능점수의 기능은 사용자에게 의미있는(주로 UI를 가지는) 것만 도출하기 때문이다.
-?????? 하지만 이런 기능을 개발비에서 누락시킬 수 없다면, 사용자에게 의미있는 것 같은 이름으로 기능을 도출하라. 위에서 얘기했듯이, 검증기관은 기능 자체의 적정성을 파악할 수 없으므로, 이름과 유형만 맞으면 된다.
-?????? 즉, “xxx 처리”, “xxx 전송”, “xxx 수신”, “xxx 집계”등과 같이 내부프로세스인 듯한 느낌의 이름은 피한다. 이런 이름은 거의 지적당할 수 있다. 대신 “조회”, “입력”과 같은 이름을 사용한다.
- 기능점수 검증기관은 “EO”를 검증한다.
-?????? 기능점수에서 EO를 많이 틀리게 되므로 EO가 산출되면 유심히 살피게 된다.
-?????? 대부분의 조회는 모두 “EQ”이다. 수학적 계산결과에 의한 결과를 조회하는 경우만 EO를 사용하라.
-?????? EO는 반드시 “통계”와 같은 명칭을 사용하고, EO와 EQ의 판단이 힘들다면 그냥 EQ를 사용하라.
- 개발비를 늘이고 싶다면 “기능”을 늘여라
-?????? 개발비 산정과정을 보면, 가장 쉽게 개발비를 높이는 방법은 보정계수를 높이는 방법이다.
-?????? 하지만 보정계수는 검증기관이 객관적으로 판단가능한 부분이므로, 너무 높이게 되면, 지적을 받을 수 있다. 즉, 개발비가 보정계수를 낮춤으로서 마지막에 축소될 위험이 있다.
-?????? 어플리케이션 유형의 경우, 유형별 비율을 실제 전체 기능에서 해당 유형의 기능 수를 세어서 검증하라고 요구받는 경우도 있다.
-?????? 즉, 안전하게 개발비는 높이는 방법은 기능을 늘이는 것이다.
- 기능을 늘이기 위해서는 기존 기능에 부가적인 기능을 더 도출하라
-?????? 앞에서 기능점수 검증기관은 “기능의 적정성”을 판단할 수 없다고 했다.
-?????? 또한 검증기관은 모든 요구사항을 알고 있지도 못한 경우가 많다.
-?????? 즉, 이미 만들어진 기능으 더 분할하거나, 기능에 “정보의 선택”, “유사정보의 관리”등 숨어 있는 추가 기능들을 도출하여 추가한다.
-?????? 그 기능들이 명칭과 유형이 일치하는 이상, 추가에 대한 위험은 없다. 단, 기능점수에 적힌 이상, 개발시 반드시 개발되어야 한다.
-?????? 노련한 분석자라면, 개발범위를 늘이지 않고 기능점수만을 늘이는 요령을 익힐 필요가 있다.
- 데이터 기능을 적극 활용하라
-?????? 데이터 기능을 ILF의 경우 전체 기능중에 가장 높은 평균복잡도를 가진다. 즉, 가장 금액이 비싼 기능이다.
-?????? 대부분 기능 검증 시, 트랜잭션 기능을 위주로 검증한다. 트랜잭션 기능은 EI/EO/EQ의 적정성을 검증하게 되지만, 데이터 기능은 대부분이 ILF기 때문에 크게 검증을하지 않는다.
-?????? 또한 트랜잭션기능에 기술된 항목은 실제 프로젝트 수행시, 모든 기능을 구현해야 한다. 하지만 데이터 기능은 논리적인 데이터이기 때문에 모든 것이 테이블로 구현될 필요는 없다.
-?????? 즉, 데이터 기능을 합리적으로 늘이거나 줄여서 개발비를 큰 폭으로 조정가능하다.
-?????? 개발비를 늘이고자 한다면, 데이터 기능을 많이 도출하라. 단, 도출된 데이터의 관리가 반드시 트랜잭션기능에 존재하여야 한다.
- 개발비를 낮출려면 기능을 제거하라.
-?????? 앞의 설명에 반대되는 개념이다. 예산의 한계에 의하여 개발비를 전체적으로 낮추어야 할 경우도 있는데, 이 때, 보정계수 등으로 낮추는 방법은 피하도록 한다.
-?????? 돈을 적게 받는다면, 기능을 제거하여 실제 개발범위를 줄이는 것이 바람직하다.
-?????? 만약 기능자체를 줄일 수 없는 상황이라면, EI가 3으로 책정되는 “xxx관리”계열의 기능을 “xxx입력”으로 바꾸고 EI를 1로 변경한다. EI는 복잡도가 높은 기능이므로, 전체적인 개발비가 많이 줄어들 것이다.
- 보정계수는 되도록 낮게 설정한다.
-?????? 기능점수에 익숙하지 않을 경우, 대부분 개발비를 보정계수를 이용하여 조정한다.
-?????? 보정계수는 어느 정도 기준이 명확하므로 이 경우 검증기관에 집중적인 지적을 받게 된다.
-?????? 보정계수는 되도록 낮게 설정하는 것이 안전하다. 낮을 경우 거의 지적을 받지 않는다.
-?????? 일반적인 프로젝트에서 품질/특성 보정계수의 경우, 대부분 “1”이다. 성능은 실제 성능에 대한 요구가 없거나 성능측정을 위한 도구를 사용하지 않는다면 무조건 “0”이다. 그리고, 신뢰성과 다중사이트도 요구사항이 없다면, “0”으로 설정한다.
- 개발비의 미세조정은 이윤으로 가능하다.
-?????? 이윤은 전체 개발원가의 0%에서 25%까지 설정가능하다.
-?????? 이를 이용하여 최종 목표금액을 어느정도 조절가능하다.
