소프트웨어 비용산정 - 2

대표적 소프트웨어 비용산정 기법

Delphi 기법

델파이기법은 한 나라의 연구수준이나 미래의 특정시점을 예측하는 경우, 특히 현재의 상태에 대한 일반화표준화된 자료가 부족한 경우, 전문가적인 직관을 객관화하는 예측의 방법으로 많이 사용되어지는 기법이다. 다시 말하면 본 연구의 예측조사의 방법으로 사용되는 델파이기법은 내용이 아직 알려지지 않거나 일정한 합의점에 달하지 못한 내용에 대해 다수의 전문가의 의견을 자기기입식 설문조사방법이나 우편조사방법으로 표준화와 비표준화 도구를 활용하여 수회에 걸쳐 피드백(feedback)시켜 그들의 의견을 수렴하고 합의된 내용을 얻는, 소위 전문 집단적 사고를 통하여 체계적으로 접근하는 일종의 예측에 의한 정책분석 방법이라고 볼 수 있다. 델파이기법과 똑같지는 않지만 의도적인 면에서 비슷한 방법으로 이루어지는 브레인스토밍이 있다.

특징

델파이기법은 각 전문가들에게 개별적으로 설문서와 그 종합된 결과를 전달회수하는 과정을 거듭함으로써 독립적이고 동등한 입장에서 의견을 접근해 나갈 수 있도록 하려는 것이다. 따라서 설문서의 응답자는 철저하게 익명성이 보장되므로 외부적인 영향력으로 결론이 왜곡되거나 표현이 제한되는 예가 매우 적다. 또한, 통제된 피드백(feedback) 과정을 반복하기 때문에 주제에 대한 계속적인 관심과 사고 촉진종합된 의견의 전달은 질문서에 대한 답을 집계하는 형식으로 이루어지게 된다. 따라서 통계적으로 의견을 처리하여 제시함으로써 그룹 내의 의견 차이 정도를 보여주고, 강한 소수의견에 대해서도 내용을 파악할 수 있도록 해준다. 하지만 질문서에 의지하는 경향이 나타나므로 질문서 자체가 잘못되면 델파이조사 자체가 잘못될 수 있는 결정적인 문제점도 가지고 있다.

델파이기법의 단계

1. 관련 분야 전문가 집단 구성: 알고자 하는 내용에 대해 가장 잘 알고 있으리라고 믿어지는 전문가를 30명에서 최고 100명까지 선정하여 패널을 구성한다.

2. 1차 질문: 구성된 패널을 통해 개방형 질문을 하여 그들의 견해를 모두 나열함으로 가능한 많은 자료를 수집분석하여 항목으로 구성, 폐쇄형 질문지를 만든다.

3. 2차 질문: 이 폐쇄형 설문지를 동일 대상자에게 보내는 2차 질문을 실시한다. 이 때는 문항에 점수를 주거나 중요도를 측정하여 일정수의 중요 문항을 선택하게 한다.

4. 3차 질문: 수집된 결과를 항목별로 종합하여 전문가 전체의 항목별 도수, 평균, 또는 표준편차 등을 제시하여 다시 동일 집단에게 보내어 중요 문항을 선택하게 한다.

5. 4차 질문피드백: 셋째 단계의 결과를 가지고 면담을 실시한다. 이와 같은 방법으로 전문가들 사이에 어떤 합의점을 찾을 때까지 여러 차례의 설문을 통하여 최종 결과로 얻는다.

장점

• 편향된 토의에 쏟는 시간과 노력의 낭비를 줄일 수 있다.

• 연구자에 의해 통제되기 때문에 초점에서 크게 빗나가지 않는다.

• 시간적경제적(회의비체제비여건비 등)으로 절약할 수 있다.

• 협의회 보다 시간빈도 등이 덜 제약 받는다.

• 다수의 전문가 의견을 수렴, 피드백(feedback) 할 수 있다.

• 익명성이 있고 독립적이기 때문에 자유롭고 솔직한 전문가의 의견을 들을 수 있다.

• 몇몇 사람의 의견이나 분위기에 말려 휩쓸리지 않는다. 또한 체면이나 위신에 의해 다른 결정을 하지 않는다.

단점

• 질문지 조사방법 자체에 결함이 있을 수 있다. 또한 문제가 참여자들에게 맡겨 만지기 때문에 문제의 확실한 속뜻을 알기가 어렵다.

• 다른 질문지와 마찬가지로 회수율이 높지 않다. 조사가 1234 반복되어감에 따라 회수율은 점점 낮아지게 된다.

• 반복적 조사이기 때문에 조사를 끝내려면 장기간이 필요하다. 단기간의 조사는 용이하지 않다.

• 문제와 처리 결과를 직접 주고받을 수 없다.

• 통계적 처리 결과에 무의식적으로 따라갈 수 있다.

• 현재성을 중시하는 현대인에게 미래에의 무관심을 나타내게 할 수 있다.

• 한두 가지의 확신만을 가지고 미래를 볼 경우, 미래를 단순화 할 수 있다.

• 전문가들이 과도한 확신으로 환상적이거나 체제 전체를 판단 못하게 할 수 있다.

• 조작적 가능성도 가지고 있다.

• 참여 전문가들이 설문에 대하여 신중하지 못할 수 있다.

• 델파이조사에 의한 예측 연구는 불확실한 상황을 연구대상으로 삼고 있다는 기본적인 한계를 가지고 있다.

LOC(Line Of Cost) 기법

개념

개발자의 관점에서 크기 중심으로 소프트웨어 규모를 측정하는 방식으로 직접적으로 소프트웨어 소스코드 라인 수를 측정

계산방식

계산 방식	평가방법
오류발생률(Error Rate)	KLOC당 오류의 수
결함발생률(Defect Rate)	KLOC당 결함의 수
비용효율성(Cost Effectiveness)	LOC당 비용(원)
문서화(Documentation)	KLOC당 문서의 페이지 수
기타	오류의 수/월 인원 LOC/월 인원 원/Page 수

장점

• 측정하기 쉽고 이해하기 쉬움

• 기존의 많은 프로젝트 측정 모델들은 주요 입력으로 LOC를 이용하고 있음

• LOC를 중심으로 예측하는 자료들이 이미 충분히 존재

• 많은 측정 모델이 LOC를 중요한 입력값으로 사용

단점

• LOC 측정은 프로그래밍 언어에 의존

• LOC 척도는 잘 설계된 짧은 프로그램 일수록 불리함

• 개발 초기의 계획 및 분석단계에서 정확한 LOC를 측정하는 것은 불가능 하다.

• 프로그래밍 언어에 따라 크기가 가변적인 LOC의 기준이 모호하고 표준이 결여 되어 있음.

FP(Function Point)

기존에는 소프트웨어의 비용산정시에 간단하게 비용을 계산 할 수 있는 LOC 방식이 사용되었다. 하지만 LOC는 소프트웨어의 비용을 산정 할때 “양” 적인 측면만을 강조하고 “기능”적인 측면의 비용산정에는 문제가 많았다. 이러한 LOC의 문제점을 해결하고 사용자 관점의 기능과 양을 고려한 비용산정 기법이 Function Point이다.

개념

• 소프트웨어의 크기를 결정하는 소프트웨어 기능유형별 수량과 성능 및 품질 요인들이 영향도를 고려하여 계산되는 수치

• 기능점수 요소들은 소프트웨어 정보 영역의 가산적 척도들과 소프트웨어 복잡성에 대한 주관적 측정을 기초로 한 실험, 관찰에 의한 관계성을 이용하여 유도 됨.

• Application 크기를 결정하는 Application 기능유형별 수량과 성능 및 품질 요인들의 영향도를 고려하여 계산되는 수치

• 기능증대 요인의 수 및 요인별 난이도 가중치를 정하여 기본 기능 점수를 계산

기능점수 유형

• EI(External Input) 외부입력

시스템(소프트웨어시스템을 의미)의경계 밖에서 시스템에 데이터를 입력하는 기능

• EO(External Output) 외부출력

시스템의 경계밖으로 데이터를 출력하는 기능

• EQ(External inquiries) 외부조회

입력이 출력을 즉시요구하는 입력/출력 조합을 외부조회로 판단한다. 입력 또는 출력중의 하나라도 포맷이 다르거나, 내부 처리로직이 다르면 별개의 기능으로하마.

• ILF(Internal Logical Files) 내부논리파일

시스템내에서 논리적으로 유지되는 파일로서 사용자 관점에서 볼때 시스템에 의해 생성되고, 사용되며, 또한 관리되는 논리적인 데이터의 그룹

• EIF(External Interface Files) 외부인터페이스파일

응용시스템간에 공유되거나 전송되는 파일로서 시스템 밖의 응용시스템이 논리적으로 유지하는 파일

FP 계산방식

가) 측정 유형결정

유형	내 용
개발프로젝트 기능점수	DFP : Development Function Point à 개발완료시 SI 개발 프로젝트에 사용 프로젝트가 종료된 후 고객에게 인도된 소프트웨어기능 측정
개선프로젝트 기능점수	EFP : Enhancement FP à 개선요구 사항 완료시 유지보수 및 아웃소싱 사업에 사용 추가, 삭제, 수정 부분에 대한 소프트웨어 기능을 측정
애플리케이션 기능점수	AFP : Application FP à 개선요구사항 완료 후 FP 재계산 시 토털 아웃소싱 또는 패키지에 적용 사용자가 현재 사용중인 어플리케이션의 기능을 측정

나) 측정범위와 애플리케이션 경계식별

구분	내용
측정범위	규모측정대상의 소프트웨어 집합
애플리케이션 경계	측정대상 소프트웨어와 사용자간 경계로 개념적 인터페이스

다) 데이터 기능 측정

데이터 기능점수 산정은 먼저 앞에서 나온 ILF와 EIF를 식별하는 것이다. ILF와 EIF를 식별하면 각각 복잡도와 기여도를 결정하여 데이터 기능점수를 도출한다.

라) 트랜잭션 기능 측정

트랜잭션 기능점수는 사용자가 식별 할 수 있고 최소한의 업무를 처리 할 수 있는 단위 프로세스를 식별하고 각 단위 프로세스 별로 EI/EO/EQ로 분류한 다음 복잡도와 기여도를 계산하여 트랜잭션 기능 점수를 계산한다.

마) 미조정 기능 점수 결정

데이터 기능과 트랜잭션 기능의 복잡도에 대한 기여 규칙을 적용하는 것임

바) 조정인자 결정

조정인자(VAF : Value Adjustment Factor)는 측정되는 애플리케이션의 일반적 기능에 등급을 부여한 14개의 일반적 특성에 기반한다.

• 데이터 통신 (Data Communication)

• 분산 데이터 처리 (Distributed Data Processing)

• 시스템 성능 (System Performance)

• 자원 제약 정도 (Heavily Used Configuration)

• 트랜잭션 비율 (Transaction Rate)

• 온라인 데이터 비율 (OnLine Data Entry)

• 최종 사용자 효율성 (EndUser Efficiency)

• 온라인 갱신 (OnLine Update)

• 처리 복잡도 (Complex Processing)

• 재사용성 (Reusability)

• 설치용이성 (Installation Ease)

• 운영용이성 (Operational Ease)

• 다중 설치성 (Multiple Sites)

• 변경 용이성 (Facilitate Change)

조정인자 결정절차	내용
영향도 결정	14개 일반 시스템 특성에 0~5점으로 각각 평가
총영향도 결정	14개 일반 특성의 영향도를 합해서 총영향도 계산
조정인가 계산	총영향도는 방정식에 대입해서 계산 조정인자(VAF) = (총영향도X0.01)+0.65

사) 조정 기능 점수 결정

기능점수 분석의 마지막 단계로 측정타입별(개발 프로젝트, 개선 프로젝트, 애플리케이션)로 구성요소간 계산식에 의해 조정 기능 점수를 도출한다.

FP의 장점

• 프로그래밍 언어에 독립적이어서 일반언어 또는 비절차적 언어에도 적용 가능

• 중복을 지양한 짧은 코드 불이익 해소

• 소스크기 뿐 아니라 복잡도 등 적용

• 프로젝트 개발 초리에 쉽게 알려질 수 있는 자료에 기초하여 작성

FP의 단점

• 주관적 자료(복잡도)에 기초 계산

• 능숙한 기술과 축적된 경험있는 전문가 필요

• 프로젝트 영역 정보수집 곤란

• 개발초기 알려질 수 있는 자료 저조

비용산정의 문제점

• 개발 기술이 발전되고 환경이 변화함에 따라 규모 견적은 더욱 어려워지고 있음

• LOC는 점점 그 효용성을 잃어가고 있고 그 대안인 기능점수를 도입하여 사용함에 도 문제점을 안고 있음.

• 국내 상황에서는 견적시기의 문제와 계약방식의 문제가 함께 겹쳐 있어 개선안이 필요함

• 프로젝트를 진행하는데 필요한 원가와 대가의 차이

• 기업의 이윤을 고려하지 않는 순수 원가

• 적정이윤을 보장하고 기술개발 활동을 인정하는 대가 필요

• 적정선 도출을 위한 실 데이터의 축적 과제

비용산정의 해결방안

• 비용과 관련 위험에 대한 식별과 그 위험을 통제하기 위한 프로젝트 관리방안 수립

• 비용에 대한 위험 요소를 계량화하여 그 위험에 대한 대응방안을 개발해야 함

• 위험을 최소화하여 회피하기 위한 위험 감소전략을 개발해야 함

• 비용에 대한 위험을 지속적으로 추적하고 통제해야 함

• 소프트웨어가 소비재가 아닌 국가적인 지식기반의 자산관리 측면의 접근 필요

• 자산으로 관리하기 위한 객관적 판단 가치를 평가 Tool로 기능점수를 도입