KR20060047546A - 소프트웨어 개발 공수 비용의 평가 장치 - Google Patents

Abstract

본 발명은 소프트웨어 개발 공수(工數; manpower) 비용의 평가를 객관적으로 또한 공정한 방법으로 할 수 있는 소프트웨어 개발 공수 비용의 평가 방법에 관한 것으로서, 소프트웨어의 기능 규모(function point)를 생산성 계수의 곱셈값으로 나눗셈하고, 그 나눗셈값과 부대(附帶) 작업 공수와의 가산값에 시스템 엔지니어 단가를 곱셈함으로써 상기 소프트웨어의 개발 비용의 견적 및 평가를 행한다.

공수, 기능 포인트, 시스템 엔지니어, 소프트웨어

Description

소프트웨어 개발 공수 비용의 평가 장치 {EVALUATION APPARATUS FOR EVALUATING SOFTWARE DEVELOPMENT MANPOWER/COST}

도 1은 FP를 구하는 방법을 나타낸 도면이다.

도 2는 FP와 평가액의 관계예를 나타낸 특성도이다.

도 3은 본 발명의 원리를 나타낸 모식도이다.

도 4는 본 발명의 평가값 산출 장치를 나타낸 블록 구성도이다.

도 5는 연산부의 구성예를 나타낸 블록도이다.

도 6은 본 발명의 동작예를 나타낸 플로 차트이다.

도 7은 본 발명의 다른 동작예를 나타낸 플로 차트이다.

도 8은 본 발명에 의한 신규 개발 및 개수(改修) 안건의 개발 규모, 공수(工數; manpower), 비용의 산출 방법을 나타낸 도면이다.

도 9는 FP법의 개략을 나타낸 도면이다.

도 10은 개발 규모 산출을 위한 입력 정보와 산출 방법을 나타낸 도면이다.

도 11은 시스템 개발 비용의 구성을 나타낸 도면이다.

도 12는 개발 프로세스의 범위를 나타낸 도면이다.

도 13은 공정 구분과 SLCP를 비교한 것을 나타낸 도면이다.

도 14는 개발 언어별 생산성값의 일례를 나타낸 도면이다.

도 15는 개발 생산성 조정 계수의 예를 나타낸 도면이다.

도 16은 공정 배분 비율의 예를 나타낸 도면이다.

도 17은 작업 분담 비율의 예를 나타낸 도면이다.

도 18은 소프트웨어 개발 기술자의 직종 구분과 역할을 나타낸 도면이다.

도 19는 본 발명의 입력 화면의 일례를 나타낸 도면이다.

도 20은 본 발명의 결과를 나타내는 표시 화면의 일례를 나타낸 도면이다.

도 21은 FP를 활용한 참고 가격의 검증예를 나타낸 도면이다.

<부호의 설명>

10: 연산부(CPU)

102: ROM

103: RAM

110: 입력 수단

120: 표시 수단

121: 인쇄 수단

1031: 개발 언어별 생산성값 테이블 기억 수단

1032: 생산성 조정 계수 테이블 기억 수단

1033: 개발 공정별 표준 배분율 테이블 기억 수단

1034: 표준 테스트 항목 건수 테이블 기억 수단

1035: 시스템 엔지니어 단가 금액 테이블 기억 수단

본 발명은, 컴퓨터 시스템, 네트워크 등을 구성하는 소프트웨어의 개발 공수(工數) 비용의 가격(견적액)을, 가능한 객관적이며 또한 합리성을 가지고 평가하기 위한 소프트웨어 개발 공수 비용 견적 프로그램 및 소프트웨어 개발 공수 비용 견적 프로그램을 기억시킨 기억 매체에 관한 것이다.

정보 시스템이 업무나 사회 곳곳에 보급되고, 거기에 따른 정보 시스템의 투자가 방대해 지고, 그 중에서도 소프트웨어 개발비가 큰 비율을 차지하고 있다. 그러나, 소프트웨어 개발비(평가)의 견적 프로세스가 구조화되어 있지 않으므로, 벤더(vendor)가 제시한 견적은 때때로 명확한 근거가 제시되지 않은 채, 발주 및 시스템 구축 등의 업무가 수행되고 있는 실정이다.

종래 컴퓨터 시스템을 구성하는 소프트웨어의 개발 공수 비용을 견적을 내는 경우, 소프트웨어의 규모나 작업 내용을 고려하여 개발 공수 비용을 산출하는 것이 일반적이다. 그 때문에, 소프트웨어 개발 공수 비용의 견적이나 평가 작업은, 소프트웨어 개발 작업에 오랫동안 종사한 전문가와 같은 특정한 사람의 경험과 감(感)에 의존하는 경우가 많다.

소프트웨어 개발 공수 비용의 견적을 내거나 평가하는 방법으로서, LOC(Lines of Code: 프로그램 행수)법이 존재하지만, 1990년대부터 IT 기술의 진보에 따라, 시스템 구성과 개발 방법의 다양화와 복잡화가 이루어지고, 이제는 프로그램 행수와 개발 공수 및 비용과의 상관 관계가 무너지고, LOC법으로 길러온 경험 이나 감에 의해 견적을 내는 것은 한계에 와 있다. 그래서, LOC법을 대신하여 FP(Function Point: 기능 규모)법이 주목되고 있다. FP법은 소프트웨어가 가지는 기능의 양을 측정하는 방법으로서, 도 1에 나타낸 것처럼 시스템 사양서(仕樣書)에의해 규모를 정량적으로 계측하여 소프트웨어 기능 규모를 계산하는 방법이다. 소프트웨어 개발 공수나 비용을 산정할 때에 사용되고 있는 FP에 대한 평가액은, 일반적으로 도 2에 나타낸 것과 같은 2차 함수가 된다.

또한, 일본국 특개2002-222080에 개시된 소프트웨어 견적 시스템에는, 소프트웨어 기능 정보가 기억된 기능 정보 기어부과, 상기 기능 정보 기억부에 기억된 기능 정보에서 개발하는 소프트웨어 프로젝트의 기능 정보를 선택하는 기능 정보 선택부와, 상기 기능 정보 선택부에 의해 선택된 기능 정보를 이용하여 상기 소프트웨어 프로젝트의 기능량을 계산하는 기능량 계산부를 구비하고 있어서, 업무 분야와 규모를 개발 비용의 견적에 이용하고 있다.

일본국 특개2003-263320에 개시된 견적 작업 지원 시시템은, 개발 대상 시스템의 견적 작업을 지원하는 견적 작업 지원 시스템이고, 개발 대상 시스템의 소프트웨어 규모를 견적하기 위한 규모 견적 조건을 입력하고, 개발 견적 조건에 따라 소프트웨어 규모를 견적하는 소프트웨어 규모 견적 수단과, 개발 공수를 견적하기 위한 공수 견적 조건을 입력하고, 공수 견적 조건에 따라 개발 공수를 견적하는 개발 공수 견적 수단과, 개발 비용을 견적하기 위해 비용 견적 조건을 입력하고, 비용 견적 조건에 따라 개발 비용을 견적하는 개발 비용 견적 수단과, 소프트웨어 규모의 견적 결과, 개발 공수의 견적 결과, 및 개발 비용의 견적 결과를, 견적 작업 을 행하는 작업자에게 제시하는 견적 결과 제시 수단을 구비하고 있다. 개발 비용의 견적은, 공수에 대한 단가의 곱셈값에 간접 비용을 가산하고 있다.

또한, 일본국 특개2003-308449에 개시된 시스템 개발 견적 지원 시스템은, 개발 대상이 되는 시스템의 규모 정보를 산출하기 위한 규모 산출 정보와, 시스템 개발에 필요한 인원이나 기간인 개발 공수 비용 정보를 산출하기 위한 개발 공수 산출 비용을 클라이언트 머신으로부터 수신하는 정보 수신 시스템과, 상기 정보 수신 수단에 의해 수신한 상기 규모 산출 정보에 따라 시스템 규모 정보를 산출하기 위한 규모 산출 함수 정보와, 상기 개발 공수 산출 정보에 따라 개발 공수 정보를 산출하기 위한 개발 공수 산출 함수 정보를 기억하는 산출 함수 정보 기억 수단과, 상기 개발 공수 정보를 산출하는 견적 산출 수단과, 상기 견적 산출 수단에 의해 산출된 개발 공수 정보와 상기 규모 산출 정보를 관련해서 기억하는 개발 공수 정보 기억 수단과, 상기 개발 공수 정보 기억 수단에 기억된 상기 개발 공수 정보를 상기 클라이언트 머신에 송신하는 정보 송신 수단과, 이러한 각 수단의 동작을 제어하는 처리 장치를 구비한 시스템 개발 견적 지원 시스템으로서, 상기 처리 장치는, 상기 견적 산출 수단에, 상기 산출 함수 정보 기억 수단에 기억된 상기 규모 산출 함수 정보와 상기 기억 수단에 기억된 상기 규모 산출 정보를 취득시켜, 이들 정보에 따라 시스템 규모 정보를 산출시켜, 상기 산출 함수 정보 기억 수단에 기억된 상기 개발 공수 산출 함수 정보와, 산출된 상기 시스템 규모 정보와, 상기 기억 수단에 기억된 상기 개발 공수 산출 정보를 취득시키고, 이들 정보에 따라 상기 개발 공수 정보를 산출시키는 것이다.

상기와 같이 종래의 일반적인 평가 방법으로는 그 평가값에 객관적이고 합리적인 근거가 없어서, 과연 적정한 평가액인지의 여부가 문제이며, 소프트웨어 개발 공수 비용의 평가를 객관적이며 합리성을 가지고 실행할 수 있기를, 발주자 측 및 수주 측이 함께 바라고 있었다. FP값을 사용한 평가법도 마찬가지이다.

일본국 특개2002-222080에 기재된 소프트웨어 견적 시스템에서는, 개발 분야 마다 FP산출에 필요한 정보를 미리 준비해 두고, 그것들을 호출(呼出)하여 소프트웨어 견적에 이용하도록 하고 있어서, 정보 관리가 번잡한 문제가 있다. 또한 개발 언어별 생산성은 고려되어 있지 않고, 생산성 조정도 불가능하며, 비용 견적이 불완전하다.

또, 일본국 특개2003-263320에 기재된 견적 작업 지원 시스템은 개발 공수의 견적 및 개발 비용의 견적을 행하는 일련의 견적 작업 전체를 지원할 수 있도록 하고 있지만, 개발 대상 시스템의 소프트웨어 규모를 견적하기 위한 규모 견적 조건을 입력하고, 규모 견적 조건에 따라 소프트웨어 규모를 견적하고, 개발 공수를 견적하기 위한 공수 견적 조건을 입력하고, 공수 견적 조건에 따라 개발 공수를 견적하고, 개발 비용을 견적하기 위한 비용 견적 조건을 입력하고, 비용 견적 조건에 따라 개발 비용을 견적하도록 하고 있으므로, 개발 비용을 신속히 계산할 수 없다. 또한, 개발 언어별 생산성값은 고려되어 있지 않고, 생산성 조정 계수가 제공 측을 대상으로 한 것어서, 조달 측이 이용할 수 없는 문제가 있다.

일본국 특개2003-308449는 조정 계수에 제공 측(개발 업자) 관점이 강하고, 조달 측(사용 기업)의 관점과 상이하다는 문제가 있다. 예를 들어, 개발 언어 경험 년수, 리더의 프로젝트 관리 능력, 개발 지원 툴의 숙지도 등, 제공 측의 노력 사항을 개발 공수 비용의 견적에 반영해 버리면, 제공 측에서 조달 측으로 비용을 전가하게 된다. 상기 특개2003-308449에 기재된 시스템 개발 견적 지원 시스템에서는, 개발 언어별 생산성값은 고려되어 있지 않다. 또한, 조정 계수를 주관적으로 설정함과 동시에 조정 계수의 설정이 번잡하여서, 실무면에서 좀 더 간편하고, 누구나 설정 방법을 보면, 같은 결과가 설정되도록 객관적인 설정 방법이 요구되고 있다.

또한, 상기 특허들에 기재된 것은, 모두 신규 안건에 대한 견적이며, 개수 안건에 대응할 수 없는 문제가 있다. 실무에 있어서 시스템 안건의 60 ∼ 80%정도가 보수 안건이므로, 여기에 대응하지 못하면 비지니스 효과가 반감되게 된다.

본 발명은 상기와 같은 사정에 의해 이루어진 것으로서, 본 발명의 목적은 소프트웨어 개발 공수 비용의 평가를 객관적이며 공정한 방법으로, 또한 간이 시스템으로 합리성을 가지고 행할 수 있는 소프트웨어 개발 공수 비용의 평가 방법, 평가값 산출 장치 및 프로그램을 제공하는데 있다. 즉, 본 발명은 다양한 환경이나 여러가지 개발 언어에 대응 가능하며, 다수 기업에 이용되고, 객관적으로 비교 및 검정 가능하고, 실장(實裝)에 좌우되지않고 논리적 시점에서, 관계자의 납득과 이해를 얻을 수 있고, 시스템 구축의 조기 단계에서의 계측이 가능하여, 속인성(屬人性)을 배제한 접근(approach)이 가능한 소프트웨어 개발 공수 비용 견적 프로그램 및 소프트웨어 개발 공수 비용 견적 프로그램을 기억한 기억 매체를 제공하는 것을 목적으로 한다.

본 발명은 소프트웨어 개발 공수 비용의 평가 장치에 관한 것으로서, 본 발명의 상기 목적은, 소프트웨어의 기능 규모를 나타내는 기능 포인트값을 기본으로 해서, 평가 대상의 소프트웨어의 개발 상황 및 시스템 환경을 고려한 평가 요소에 따라서 상기 기능 포인트값에 가중(加重)을 두고, 상기 소프트웨어의 개발 공수/비용을 평가하는 평가 장치로서, 소프트웨어의 일인당 개발 언어별 생산성을 정량화한 생산값을 기억하는 개발 언어별 생산값 테이블과, 상기 생산값을 조정하는 계수로서, 시스템 규모 계수, 및 시스템 환경을 그 형태에 따라 분류해서 정량화한 시스템 환경 계수를 포함하는 각 계수를 기억하는 생산성 조정 계수 테이블과, 소프트웨어 개발 언어와 그 이용 비율, 상기 시스템 환경의 분류 항목, 상기 시스템 규모의 분류 항목, 시스템 엔지니어 단가 금액을 포함하는 정보의 입력 화면을 표시하는 표시 수단과, 상기 입력 화면 상에서, 선택된 상기 개발 언어에 따라서, 상기 개발 언어 별 생산값 테이블에서 얻은 상기 소프트웨어 개발 언어에 대응하는 상기 생산성값, 및 상기 입력 화면 상에서 입력된 상기 이용 비율에 따라서, 소프트웨어 언어를 평가 요소로 하는 소프트웨어 개발 언어별 생산값을 산출하는 수단과, 상기 소프트웨어의 기본 설계, 상세 설계, 프로그램 설계 및 제조, 소프트웨어 테스트 및 시스템 테스트의 각 공정에 있어서의 상기 개발 언어별 생산성값 및 상기 생산성 조정 계수, 및, 상기 각 공정에 있어서의 공정별 발주율, 상기 소프트웨어의 발주 측과 수주 측과의 작업 비율을 나타내는 삭업 분담율 및 기존 시스템에 대한 개수비율을 나타내는 개수율의 입력 정보에 따라서 상기 소프트웨어의 생산성 계수를 산출하는 수단과, 상기 각 공정에 있어서의 상기 기능 포인트값을 상기 생산성 계수로 나누어서 상기 소프트웨어의 표준 개발 작업 공수를 산정하는 개발 공수 산정 수단과, 상기 표준 개발 작업 공수, 및 상기 시스템 엔지니어 단가 금액의 입력 정보에 따라서 상기 소프트웨어의 개발 비용을 산정하는 개발 비용 산정 수단과, 상기 개발 공수 산정 수단에 의해 산정한 상기 표준 개발 작업 공수, 및 상기 개발 비용 산정 수단에 의해 산정한 상기 개발 비용을 상기 소프트웨어의 개발 공수/비용의 평가 정보로서 출력하는 평가 정보 출력 수단을 구비하는 것에 의해 달성된다.

또한, 본 발명의 상기 목적은, 상기 평가 요소로서 업자 제시 가격을 포함하고, 상기 평가 정보 출력 수단은, 상기 개발 비용 산정 수단에 의해 산정한 상기 개발 비용을 평가용 기준 가격으로서, 그 평가용 기준 가격과 상기 입력 화면상에서 입력된 상기 업자 제시 가격을 비교한 정보를 출력하는 것과, 상기 평가 정보 출력 수단은, 상기 표준 개발 작업 공수의 합계 및 상기 개발 비용의 합계를 출력함과 함께, 상기 표준 개발 작업 공수 및 상기 개발 비용을 상기 공정별로 출력하는 것에 의해 각각 한층 효과적으로 달성된다.

또한, 본 발명의 상기 목적은, 상기 생산성 조정 계수 테이블에는, 데이터와 프로세스의 집중 처리 및 분산 처리를 포함하는 처리 형태에 따른 개발 작업 부하를 상기 처리 형태에 의해 분류하여 정형화한 처리 부하 계수, 및, 문서에 관한 생산성을 문서의 종류 및 수량에 의해 분류하여 정량화한 문서 계수가 추가로 기억되어 있고, 상기 표시 수단은, 상기 처리 부하 계수의 분류 항목, 상기 품질 요구 계 수의 분류 항목 및 상기 문서 계수의 분류 항목의 각 선택 메뉴를 상기 입력 화면에 표시하고, 상기 생산성 조정 계수를 산출하는 수단은, 상기 각 선택 메뉴 중에서 선택된 상기 처리 부하 계수의 항목, 상기 품질 요구 계수의 항목 및 상기 문서 계수의 항목에 각각 대응하는 상기 처리 부하 계수, 상기 품질 요구 계수 및 상기 문서 계수를 상기 생산성 조정 계수 테이블에서 얻고, 그러한 계수, 상기 시스템 규모 계수, 및 상기 시스템 환경 계수에 따라서 상기 생산성 조정 계수를 산출하는 것과, 상기 각 공정별로 설정된 표준 발주율을 기억하는 개발 공정별 표준 배분율 테이블을 구비하고, 상기 생산성 계수를 산출하는 수단은, 상기 공정별 발주율이 입력되어 있지 않은 경우에는, 입력되지 않은 공정에 대응하는 상기 표준 발주율을 상기 개발 공정별 표준 배분율 테이블에서 얻고, 상기 표준 발주율을 상기 공정에 있어서 상기 공정별 발주율로서 상기 생산성 계수를 산출하는 것에 의해, 각각 한층 효과적으로 달성된다.

또한, 본 발명의 상기 목적은, 상기 소프트웨어가 신규 개발의 경우, 상기 개수율을 100%로 해서 상기 소프트웨어의 생산성 계수가 산출되는 것과, 상기 평가 표준으로서, 상기 소프트웨어의 표준 개발 작업 이외에 발주자로부터 제공자에게 위탁된 작업의 공수를 나타내는 부대(附帶) 작업 공정을 포함하고, 상기 개발 비용 산정 수단은, 상기 표준 개발 작업 공수와 상기 부대 작업 공수의 합에 상기 시스템 엔지니어 단가 금액을 곱해서 상기 개발 비용을 산정하는 것과, 상기 기능 포인트값은, IFPUG(International Function Point Users Group)법, 개산법(槪算法), 논리 파일 추정법 또는 스텝 산정법 중 어느 하나의 방법을 사용하여 산출한 기능 포 인트값인 것에 의해, 각각 한층 효과적으로 달성된다.

본 발명은 FP(기능 포인트)를 소프트웨어 평가의 기본으로 하고, 소프트웨어의 개발 상황이나 시스템 환경을 고려한 요소를 평가 조건으로 해서 가중하여 평가값 연산에 이용하고 있고, 또한, 평가를 위한 입력 조건이 합리적인 이유를 가지고 있어서, 개인적인 경험이나 감에 의존하지 않고, 객관성이 있는 공정한 소프트웨어 개발 비용의 평가를 얻을 수 있다.

본 발명은 신규 및 개수, 양쪽의 소프트웨어 개발 안건을 대상으로 하고 있지만, 하드웨어, 네트워크, 미들웨어(middleware) 등의 설계, 도입 작업비 등은 평가 대상으로 하지 않는다. 또한, 시스템 개발 프로세스 중, SLCP(Software Life Cycle Process: 소프트웨어를 중심으로 한 시스템의 개발 및 거래의 명확화를 목적으로, 소프트웨어 또는 시스템의 구성에서 운영이나 보수에 이르기까지의 소프트웨어 라이프 사이클을 가시화하고, 공통적인 틀을 규정한 것으로서, 「공통 프레임」이라고 함) 개발 프로세스(개발 프로세스 개시의 준비 ∼ 소프트웨어 수용 지원)의 견적을 FP법 견적 평가의 대상 범위로 한다. 그 외의 기획이나 입안 등의 컨설턴트 업무, 데이터의 이행(移行)이나 운용 지원 업무 등의 부대 작업의 견적은, 작업 축적 방식으로 평가하지만, FP 평가의 대상은 아니다. 또한, 본 발명에서는, 신규 안건과 개수 안건, 양쪽 다 개발 비용 평가 대상으로 하고 있다.

견적의 전제가 기본 설계 완료 전일 경우의 입력 정보는, 요건 정의서 및 전표, 장부, 화면, 마스터 파일 일람이며, NESMA 제안의 개산법(槪算法)으로 견적을 행한다. 즉, 마스터 파일의 일람을 기본으로 요건 정의서의 내용을 참조하고, 실무적인 관점에서 ILF(International Logic File: 계측 대상 시스템인 자(自) 시스템이 유지 관리하고 있는 논리 마스터)와 EIF(External Interface File: 자 시스템이 참조하고 있는 타 시스템(계측 대상 시스템과 관련한 시스템)이 유지 관리하고 있는 논리 마스터)를 특정하고, FP 규모를 산출한다. 또한, NESMA는 폴란드의 FP법 추진 단체이고, NESMA가 IFPUG법을 개량해서 시스템 개발의 조기 단계에 적용할 수 있는 개산법을 제안했다.

또한, 견적의 전제가 기본 설계 완료 후인 경우의 견적 입력 정보는, 요구 사양서 및 기본 설계서, 화면 일람 및 기본 사양, 장부 일람 및 장부 사양, 마스터 파일 일람 및 마스터 파일 사양, 인터페이스 파일 일람 및 인터페이스 파일 사양이다. 그리고, 견적 방법은 IFPUG(International Function Point Users Group)법으로 기능을 조사하여, 각 기능마다 복잡도를 평가하고, 미조정 기능 규모(FP)를 산출하게 되어 있다.

대부분의 기업에서 비지니스 업무의 자동화(컴퓨터화)가 이루어져 있으므로, 현재 시스템화 안건 중, 신규 개발 안건(20 ∼ 40%)이 적고, 대부분 보수 안건(60 ∼ 80%)이다. 그 때문에, 보수 비용의 견적 평가는 중요한 업무가 되고 있다. 그러나 FP법(IFPUG법)으로는, 보수 신건에 있어서 규모 계측은 보수의 모체(추가, 변경 및 삭제하는 대상 기능) 밖에 계측할 수 없기 때문에, 동일 시스템에 대한 보수라 하더라도, 경미한 보수와 중대한 보수 등, 상태에 따라서 드는 시간과 비용이 크게 다르다. 보수의 정도를 측정하여 보수 비용을 견적하고, 또는 조달 측이 그 것을 평가하는 것이 불가결하게 되어 있다. 이러한 이유로 해서, 본 발명에서는 신규 안건뿐만 아니라, 개수 안건도 평가 대상으로 하고 있다.

이하, 본 발명의 실시예를 도면을 참조하여 설명한다.

도 3은 본 발명의 원리를 모식적으로 나타내고 있고, 소정의 방법으로 구한 FP값에 대해 생산성 모델으로부터 생산성에 관한 정보를 부여하고, 다음에 개발 공수의 일인당 월 단가(이하, 인월 단가, 혹은 시스템 엔지니어 단가 금액이라고도 함)를 입력하고, 소정 연산식에 따라서 소프트웨어 개발 공수 비용을 산출한다. 생산성 모델에 따른 생산성에 관한 정보를 FP값에 추가하여 개발 공수 등을 산출하기 때문에, 객관적이고 공정한 평가를 행할 수 있다.

그리고, 생산성은, 한사람이 일개월 당 "xxFP"의 시스템을 개발할 수 있는 지표를 나타내고 있고, 생산 모델에 대해서는 후술하지만, (개발 언어별 생산성값 × 시스템 환경 계수 × 시스템 규모 계수 × 처리 부하 계수 × 품질 요구 계수 × 문서 계수 × 공정별 발주율 × 작업 분담율 × 개수율)을 나타내고 있다.

도 4는 본 발명의 평가값 산출 장치(컴퓨터)의 구성예를 나타내고 컴퓨터에 구비한 입력 수단에 의해 별도 산출된 시스템 환경 계수, 시스템 규모 계수, 처리 부하 계수, 품질 요구 계수, 문서 계수, 공정별 발주율, 작업 분담율, 개수율 등의 조건 데이터(C₁ ∼ C_n)가 입력되고, 또한 시스템 평가를 위한 평가용 데이터가 평가용 데이터 테이블에 입력된다. 연산부(10)는 입력된 FP, 각 조건 데이터 및 평가용 데이터 테이블에 따라서 평가값(견적)을 산출하여, 표시 혹은 인쇄하여 출력한 다. 산출된 평가값은, FP를 기본으로 각 조건 데이터 및 평가용 데이터 테이블을 추가하여 산출되고 있기 때문에, 객관적이며 공정한 평가값이 된다. 그리고, 평가용 데이터 테이블은 후술하는 개발 언어별 생산값 테이블, 생산성 조정 계수 테이블, 개발 공정별 표준 배분율 테이블, 표준 테스트 항목 건수 테이블 등의 데이터가 된다.

도 5는 컴퓨터의 상세한 구성예를 나타내고 있고, 전체의 제어나 연산을 실행하는 연산부(CPU)(101)에는 동작 프로그램을 저장한 ROM(102)과, 각종 데이터를 입력하는 입력 수단(110)과, 개발 언어별 생산성값 테이블 기억 수단(1031), 생산성 조정 계수 테이블 기억 수단(1032), 개발 공정별 배분율 테이블 기억 수단(1033), 표준 테스트 항목 건수 테이블 기억 수단(1034) 및 시스템 엔지니어 단가 금액 테이블 기억 수단(1035)을 내부에 포함하는 RAM(103)과, 데이터 등을 표시하는 표시 수단(120)과 데이터 등을 인쇄하여 출력하는 인쇄 수단(121)으로 구성되어 있다.

개발 언어별 생산성값 테이블 기억 수단(1031)에는, 이용되는 언어마다 설정된 1인당 월 생산성값이 기억된다. 생산성 조정 계수 테이블 기억 수단(1032)에는, 후술하는 시스템 규모 계수, 시스템 환경 계수, 처리 부하 계수, 품질 요구 계수 및 문서 계수의 각각의 입력값에 대응하는 생산값이 기억된다. 개발 공정별 배분율 테이블 기억 수단(1033)에는, 기본 설계, 상세 설계, 프로그램 설계 및 제조, 소프트웨어 테스트 및 시스템 테스트의 각 공정에 대하여 일반적 경험 법칙에 따른 발주율이 기억된다. 표준 테스트 항목 건수 테이블 기억 수(1034)에는, 소프트웨 어 테스트 및 시스템 테스트의 각 공정에 있어서 행해지는 테스트 항목 건수에 대하여 일반적 경험 법칙에 따른 건수가 기억된다.

그리고, 일반적으로 경험 법칙에 따른 발주율은, 각각 16%, 20%, 36%, 15% 및 13%이지만, 소프트웨어의 개수 상황에 따라 입력 수단(110)으로부터 입력될 수도 있다. 또, 일반적으로 경험 법칙에 근거한 테스트 항목 건수는 통상, 소프트웨어 테스트의 기준 항목수가 FP값 × 2.0 건, 시스템 테스트의 기준 항목수가 FP값× 0.5 건이지만, 그러한 소프트웨어 분야에 따라서도 상이한 경우가 있기 때문에, 후술하는 소프트웨어 테스트 항목 건수의 적용에는 각각 기호 R5 및 R6을 사용하여 표현하고 있다. 또, 이들 테이블 기억 수단은, 연산부(10)가 제어 프로그램의 지령을 받아 미리 작성된다. 물론, 입력부(110)를 동작시켜 이들 테이블에 기억된 테이블값을 입력된 값으로 변경하는 것도 가능하다.

이와 같은 구성에 있어서, 그 동작을 도 6의 플로 차트를 참조하여 설명한다. 그리고, 이하의 각 스텝은, 연산부(10)가 ROM(102)에 기억된 제어 프로그램의 지령을 받아 동작한다.

먼저 별도로 요구된 FP가 입력 수단(110)으로부터 입력되고(스텝 S1), 이어서 대상으로 하는 시스템이 사용하는 언어에 따라, 언어별 생산성값 입력 수단(110)으로부터 언어별 생산성값, 개발 언어별 생산성값이 입력됨과 동시에(스텝 S2), 입력 수단(110)으로부터 생산성 조정 계수가 입력된다(스텝 S4). 생산성 조정 계수를 산출하는 파라미터로서 본 발명에서는, 생산성 조정 계수로서의 시스템의 플랫폼(platform)을 나타낸 시스템 환경 계수, 평가 대상 어플리케이션의 규모 를 나타낸 시스템 규모 계수, 프로세스의 형태(집중 및 분산)를 나타낸 처리 부하 계수, 시스템의 품질 요구의 정도(리뷰, 테스트 및 평가 작업)를 나타낸 품질 요구 계수, 및 작성하는 문서의 종류나 수량을 나타낸 문서 계수가 입력되어 산출 될 수도 있다. 이들 생산 성장성 계수의 파라미터로부터의 산출에 대한 자세한 것은 후술한다.

또한, 개발 프로세스(공정)의 일부를 자체 제작하거나, 1 안건을 복수 단계로 분할하여(공정별) 발주하거나, 1 안건을 복수개의 벤더에 분할하여(공정별) 발주하는 경우의 발주 비율을 나타낸 공정별 발주율(스텝 S4A), 발주 측(조달 측)과 수주 측(제공 측)과의 작업 비율을 나타낸 작업 분담율(스텝 S4B), 및 기능 개조의 경우의 개수율(스텝 S4C)이 설정되고 입력된다. 그리고, 이들의 입력 순서는 임의로 할 수도 있다.

상기와 같이 연산을 위한 조건과 데이터가 입력되면, 연산부(101)는 ROM(102) 내에 저장된 프로그램에 따라 연산을 실행하고(스텝 S5), 그 후에 입력 수단(110)에 의해 부대 작업 공수가 입력되고(스텝 S6), 소정의 연산이 실행된다(스텝 S7). 그리고, 입력 수단(110)에 의해 시스템 엔지니어 단가 금액이 입력되고(스텝 S8), 소정의 연산을 실행하여 종료한다(스텝 S9). 이로써, 소프트웨어 개발 공수 비용의 평가를 수치로 얻을 수 있고, 표시 수단(120)에서 결과를 볼 수 있음과 동시에, 인쇄 수단(121)으로 인쇄할 수 있다.

그리고, 스텝 S4A의 공정별 발주율이 입력되지 않는 경우도 있다. 이 경우, 개발 공정별 표준 배분율 테이블 기억 수단(1033)에 기억된 표준 배분율(표준 발주 율)의 데이터를 판독하여, 공정별 발주율로서 연산을 한다.

상기 예에서는 데이터를 입력할 때마다 연산하고 있지만, 도 7에 나타낸 바와 같이 모든 데이터를 입력하고 나서 연산을 행할 수도 있다. 이 경우, FP, 개발 언어별 생산성값, 생산성 조정 계수, 공정별 발주율, 작업 분담율, 개수율, 부대 작업 공수 및 SE 단가 금액의 입력은 임의의 순서로 행한다

도 8은, 본 발명에 의한 신규 개발 안건 및 개수 안건의 개발 규모, 공수, 비용을 컴퓨터에서 산출하는 방법의 흐름을 상세하게 나타내고 있고, 먼저 소프트웨어 규모(FP)의 산출을 행하고 데이터 입력을 행하지만, 본 발명에서는 IFPUG법, 개산법, 논리 파일 추정법 또는 스텝 역산법 중 어느 하나를 이용한다. IFPUG법은, ILF(Internal Logical File) + EIF(External Interface File) + EI(External Input) + EO(External Output) + EQ(External Inquiry)에서 각 기능의 가중이 있고, VAF의 조정은 없다고 되어 있으며, 개산법은, ILF + EIF + EI + EO + EQ에서 각 기능의 가중이 없고, VAF의 조정도 없다고 되어 있다. VAF(Value Adjusted Factor)는, IFPUG법으로 제시되어 있는 조정 요인(생산성 조정 계수)이다. 또, 논리 파일 추정법은 ILF수 × 35 + EIF수 × l5이고, 스텝 역산법은 언어별 스텝 수 ÷ 언어별 FP 당 스텝 수이다.

상기와 같이 하여 계산된 FP가 연산부(10)에 입력되면, 개발 언어별 생산성값 및 생산성 계수의 입력을 행한다. 즉, 개발 언어별 생산성값, 생산성 조정 계수(시스템 규모 계수, 시스템 환경 계수, 처리 부하 계수, 품질 요구 계수, 문서 계수), 공정별 발주율, 작업 분담율 및 개수율의 입력을 행한다. 소프트웨어 언어 로서는, COBOL85, Microfocus COBOL, C, C++, Visual C++, JAVA/JAVA Script, ABAP/4, Oracle Developer/2000, Access, EXCEL, PL/SQL 등이 있지만, 소프트웨어 언어에 따라 인월 생산성이 상이하다. 그러므로 사용 언어에 대한 인월 생산성을 미리 개발 언어별 생산성값 테이블(1031)에 설정해 두고, 상기 개발 시스템의 사용 언어에 따라 데이터를 판독하여 인월 생산성을 입력한다. 예를 들면 COBOL85나 C는 인월 생산성이 낮고, Visual Basic, C++ 등은 인월 생산성이 높다. 그리고, 동일 소프트웨어의 개발에 복수개의 언어를 채용했을 경우, 각각의 비율을 산출하여 전체의 개발 언어별 생산성값을 합산한다.

또, 생산성 조정 계수 내의 시스템 환경 계수는 PC스탠드어론 형태, 호스트 집중 형태, 단일 플랫폼 구성(ALLUNIX 또는 ALL Windows) 및 복식 플랫폼 구성(UNIX, Windows, LINUX)에 따라 생산성이 상이하기 때문에, 시스템 환경에 따른 계수를 설정한다. 시스템 규모 계수는 FP의값에 의해 판단하고, 규모의 대소에 따라 계수값을 바꾼다. 처리 부하 계수는 프로세스의 형태에 의해 판단하고, 단일 부문/거점에서 이용자가 적은 경우(예를 들면 로칼계나 부문 내 소규모 시스템), 단일 부문/거점에서 이용자가 많은 경우(예를 들면 프로세스 집중 처리, 호스트계), 복수 부문/거점에서 이용자가 많은 경우(예를 들면 프로세스 분산 처리, 기간(基幹)계)에서 생산성이 상이하기 때문에, 각 경우에 따라서 계수값을 바꾼다. 품질 요구 계수는 이용자로부터 특별한 품질 요구가 없는 경우(동작 확인 정도), 이용자로부터 품질 요구가 보통인 경우(마스터 상태 확인), 및 이용자로부터 엄격한 품질 요구가 있을 경우(대규모 트랜잭션(transaction)/데이터 성능 확인)에 따라서 생산 성이 상이하기 때문에, 각 경우에 따라서 계수값을 바꾼다. 문서 계수에 관해서는, 예를 들면 SLCP 예시 문서 중 작성된 것이 50% 미만인 경우, SLCP 예시 문서 중 작성되는 것이 51% ~ 100% 정도인 경우, SLCP 예시 문서 중 작성되는 것이 100%를 초과하는 경우에 따라서 생산성이 상이하기 때문에, 각 경우에 따라서 계수값을 바꾼다. 그리고, 생산성 조정 계수는 생산성 조정 계수 테이블(1032)에 저장되어 있다.

공정별 발주율은, 개발 프로세스의 일부를 자체 제작하는 경우, 1 안건을 복수 단계로 분할하여 발주하는 경우, 1 안건을 복수의 제공자에게 분할하여 발주하는 경우 등, 생산성이 상이하기 때문에, 개발 프로세스 전체를 하나로 묶어서 제공자에게 발주하는 경우의 비율을 100%로 하고, 각 경우의 비율을 입력한다. 작업 분담율은, 개발 프로세스의 일부 작업을 자체 제작하거나, 1 안건을 복수의 제공자에게 분할하여 발주하는 경우가 있고, 이와 같은 경우, 쌍방(자체 제작과 발주)의 작업 분담의 정도(원칙은 공수 베이스)를 감안하여 작업 분담율을 설정하는 것이 유효하다. 개발 프로세스의 모든 작업을 제공자에게 발주하는 경우(완전 아웃소싱)의 작업 분담율을 100%로 한다. 개수는 기존 시스템에 대하여 기능을 추가, 변경 및 삭제하는 것을 말하고, 개수 안건의 견적 평가는, 기존 모체 시스템(대상 시스템)을 신규로 개발한 경우의 개수율을 100%로 하고, 기존 모체 시스템에 대한 추가, 변경 및 삭제 비율을 정량화하여, 개수 안건 공수의 견적을 평가한다. 개수 규모는 하기 (1)식에 의해 정의된다.

개수 규모 = 개수 모체 규모 × 개수율 ·····(1)

개발 언어별 생산성값 및 생산성 조정 계수 및 공정별 발주율, 작업 분담율, 개수율이 입력된 후, 연산부(10)는 이들 입력된 FP, 개발 언어별 생산성값, 생산성 조정 계수, 공정별 발주율, 작업 분담율, 및 개수율에 대해서, 하기 (2)식에 따라 표준 개발 작업 공수 A의 연산을 행한다.

표준 개발 작업 공수 A = FP ÷ 생산성 계수

= FP ÷ (개발 언어별 생산성값 × 생산성 조정 계수 × 공정별 발주율 × 작업 분담율 × 개수율)

= FP ÷ {개발 언어별 생산성값 × 시스템 규모 계수 k1 × 시스템 환경 계수 k2 × 처리 부하 계수 k3 × 품질 요구 계수 k4 × 문서 계수k5 × 공정별 발주율 × 작업 분담율 × 개수율} ···(2)

그리고, k1 ~ k5는 도 15에 나타낸 생산성 조정 테이블 기억 수단(1032)에 기억된 조정값이다. 입력 수단(110)으로부터의 입력에 따라, 각 조정값이 적용되는 것을 나타낸다.

그 후, 입력 수단(110)으로부터 부대 작업 공수를 입력하고, 하기 (3)식의 연산을 행한다. 「부대 작업」은, 상기 표준 개발 작업 이외에 발주자로부터 제공자에게 위탁한 작업을 가리키고, 이들 작업을 수행하기 위해 발생하는 비용을 「부대 작업 공수」로 정의한다. 그리고, 하기 (3)식을 연산한다.

개발 공수 B = 표준 개발 작업 공수 A + 부대 작업 공수 ···(3)

그 후, 또한 입력 수단(110)으로부터 시스템 엔지니어 단가 금액 테이블 기 억 수단(1035)으로부터 데이터를 판독하여 시스템 엔지니어 단가 금액을 입력하고, 하기 (4)식의 연산을 행한다. 이로써, 소프트웨어 개발 비용(C = 개발 공수 × SE단가 금액)을 얻을 수 있다.

개발 비용 C = 개발 공수 B × 시스템 엔지니어 단가 금액 ···(4)

즉, 소프트웨어 개발 비용의 연산식은 하기 (5)식이 된다.

개발 비용 = {기능 규모 FP ÷ (개발 언어별 생산성값 × 생산성 조정 계수

× 공정별 발주율 × 작업 분담율 × 개수율) + 부대 작업 공수}

× 시스템 엔지니어 단가 금액 ···(5)

한편, 개발 언어별 생산성값은 예를 들면 하기 (6)식에 의해 계산되어, 미리 개발 언어별 생산성값 테이블 기억 수단(1031)에 저장되어 있다. 이 경우, 각 개발 언어별의 생산성(7.5 FP/인월 ~ 40 FP/인월)이 개발 언어별 생산성값 테이블 기억 수단(1031)에 저장되어, 이용자가 개발 언어를 선택하고, 각각의 이용 비율(개발하는 기능의 다양도)을 입력함에 따라 생산성이 자동적으로 부여된다.

개발 언어별 생산성값 = (개발 언어 #1의 생산성값 × 이용 비율 m1)

+ (개발 언어 #2의 생산성값 × 이용 비율 m2)

+ (개발 언어 #3의 생산성값 × 이용 비율 m3)

+ (개발 언어 #4의 생산성값 × 이용 비율 m4)

+ (개발 언어 #5의 생산성값 × 이용 비율 m5)

···(6)

또, 생산성 조정 계수는 하기 (7)식에 의해 계산 된다. 그리고, 각 계수는 0.80 ~ 1.20의 범위로 설정되어, 표시 수단(120)의 입력 화면을 참조하여 소정의 조정 계수가 선택 입력됨에 따라, 그값이 일의적으로 부여된다.

생산성 조정 계수 = 시스템 규모 계수 k1 × 시스템 환경 계수 k2

× 처리 부하 계수 k3 × 품질 요구 계수 k4

× 문서 계수 k5 ···(7)

그리고, 도 6에서는 개발 언어별 생산성값 및 생산성 조정 계수 등을 입력 후에 (2)식의 연산, 부대 작업 공수의 입력 후에 (3)식의 연산, 시스템 엔지니어 단가 금액의 입력 후에 (4)식의 연산을 행하도록 되어 있지만, 도 7에 나타낸 것처럼 개발 언어별 생산성값, 생산성 조정 계수 등, 부대 작업 공수 및 시스템 엔지니어 단가 금액의 입력 후에 계속해서 (2) ∼ (4)식을 연속적으로 연산하여도 된다.

이하, 본 발명의 구체예를 설명한다.

본 발명은 소프트웨어 개발(개수) 안건을 대상으로 하고, 하드웨어, 네트워크, 미들웨어 등의 설계, 도입 작업비 등은 평가의 대상으로 하지 않고, 시스템 개발 프로세스 중, SLCP 개발 프로세스(개발 프로세스 개시의 준비 ~ 소프트웨어 수용 지원)의 견적을 FP법 견적 평가의 대상 범위로 하고 있다. 그 이외의 기획이나 입안 등의 컨설턴트 업무, 데이터 이행이나 운용 지원 업무 등의 부대 작업의 견적은 「작업 축적 방식」으로 평가하지만, FP 평가의 대상은 아니다. 본 발명은, 신규 안건과 개수 안건을 대상으로 하는 점에 특징이 있다.

FP법은 소프트웨어의 규모를 측정 하기 위한 방법(척도)의 하나이며, 소프트웨어의 데이터나 기능의 개수와 복잡도를 계측함으로써, 그 소프트웨어의 기능 규 모(FP값)를 산출한다. 도 9는, 본 발명에서 채용하는 FP법을 개략적으로 나타내고 있다.

기능의 종류는 ILF, EIF, EI, EO, EQ이며, ILF는 이용자가 식별할 수 있고, 자 시스템(계측 대상 시스템)이 유지 관리하고있는 논리 데이터를 정리한 것이며, EIF는 이용자가 식별할 수 있는 타 시스템(계측 대상 시스템과 관련되는 시스템)이 유지 관리하고, 자 시스템이 참조하고 있는 논리 데이터를 정리한 것이다. 또, EI는 시스템 경계 밖으로부터 데이터를 투입하여, ILF를 유지 관리(등록, 갱신 및 삭제)하는 기능이며, EO는 ILF나 EIF를 참조하여 이용자나 타 시스템에 정보를 제공하는 기능으로서, 정보 제공에 계산식이나 도출 데이터가 포함되고, EQ는 ILF나 EIF를 참조하여 이용자나 타 시스템에 정보를 제공하는 기능으로서, 정보 제공에 계산식이나 도출 데이터는 포함되어 있지 않다.

소프트웨어의 기능 규모가 그 소프트웨어 개발 공수 및 비용과 강한 상관을 나타내기 때문에, FP값를 사용하여 개발 공수 및 비용의 견적을 내는 것을 고려할 수 있다. 예를 들면, 1인당 10 FP의 생산성으로 1000 FP의 시스템을 개발하는데 100 인월의 비용이 든다. 또한, 1 인월의 SE 단가 금액이 90 만엔의 경우, 개발 비용이 9000 만엔이 된다. 발주 측이 독자적으로 FP값을 계측하여 개발 공수 비용을 산출한다고 하고, 제공자로부터 징수한 견적의 타당성을 평가하는 것으로 하고, 본 발명에서는 상기 FP를 이용하고, 상기 (5)식을 사용하여 시스템 개발비를 견적한다.

상기 시스템 개발비 견적의 정밀도를 높이기 위해, FP값을 정확하게 계측할 필요가 있다. 만일 제공 측으로부터 FP를 취득했을 경우, 제공자가 제시한 FP값이 올바른가 아닌지는, 발주 측이 스스로 검증해야 한다.

도 10은, 개발 규모(FP) 산출을 위한 입력 정보와 산출 방법을 나타내고 있다. 즉, 견적의 전제로서 기획 입안 완료#1, 기획 입안 완료#2, 요건 정의 완료, 기본 설계 완료가 있고, 기획 입안 완료#1는 스텝 역산법으로 견적하기 위해 기존 시스템 언어별 프로그램 행수, 소스(source) 코드 및 시스템 기획 내용을 입력한다. 기획 입안 완료#2는 논리 파일 추정법으로 견적을 내기 위해서 ER일람, 마스터 데이터 일람 및 시스템 기획 내용을 입력하고, 요건 정의 완료는 개산법으로 견적을 내기 위해서 기능 요건 전체 개요, 현행 업무의 흐름, 시스템화 계획, 시스템 기능 개요, 및 기능, 화면 장부 및 DB 일람을 입력하고, 기본 설계 완료는 IFPUG법으로 견적을 내기 위해서 기능 요건, 현행 업무의 흐름, 시스템화 계획, 시스템 기능 개요, 시스템 기능 상세 및 기능, 화면 장부 및 DB 일람과 레이아웃을 입력한다.

본 발명에서는 FP법을 활용한 시스템 개발비 견적 평가를 행하지만, 본 발명에서는 특히 아래와 같이 네 가지 점에 유의하고 있다.

(1) 가능한 한 IFPUG법에 따라서 계측한다.

FP법은 IFPUG 외에도, 복수개의 방법이 존재한다. 이들은 대체로 같은 개념(concept)에 의한 것이지만, 각각의 착안점이 다르기 때문에, 계측된 FP값의 의미도 상이하게 된다. 본 발명에서는, FP의 계측 방법이나 입도(粒度)는, 「IFPUG법(국제표준규격 ISO20926: 2003: IFPUG법)」에 따른다. IFPUG법 이외의 방법을 적용 하여 산출한 FP값과 IFPUG법의 FP값과의 관련을 명확하게 할 필요가 있다.

그리고, 「국제표준규격 ISO20926: 2003: IFPUG법」으로 「기능 요건과 품질 기술 요건을 분리한다」라는 해석에 따라서, 본 발명에서는, FP는 미조정 FP로 한다. 즉, 데이터 기능과 트랜잭션(transaction) 기능의 규모를 FP로 하고, 14항목의 일반 시스템 특성을 이용한 조정은 행하지 않는다. 시스템의 품질, 기술 요건은 시스템 특성 조정 계수로 평가하고, 시스템 개발 공수 비용에 반영된다.

(2) 복수 방법의 병용을 추천한다.

IFPUG법을 적용하여 FP를 계측하는 경우, 시스템의 기본 설계를 완료하고, 또한 계측에서 필요한 입력 정보가 갖추어져 있는 것을 전제로 한다. 그러나, 실무에서는 좀 더 빠른 시기에 견적을 내는 경우가 많다. 예를 들면 요건 정의 완료 시점에서의 비용 추정 등이다. 이와 같이 조기 단계에서 FP를 계측하는 경우, 계측자가 입수할 수 있는 입력 정보(사양서)의 종류나 상세도가 한정되어 있으므로, 몇 개의 간이 계측법이 고안 되어 있다. 여기서 강조하고 싶은 것은, (a) 가능한 한 IFPUG법에 근접한 방법을 적용, (b) 간이법을 이용했을 경우, 가능한 한 복수개의 방법을 실시하고, 검증을 행하는 것이다.

(3) 견적 평가의 목적은 비용 적정화이다.

본 발명에서 제안하고 있는 시스템 개발 비용의 견적 평가 방법은, 개발 프로세스의 표준업(標準業)을 대상으로 하고 있다. 실무에서의 시스템 개발 안건은, 개발 프로세스의 일부만 발주하지 않는가, 또는 개발 프로세스 이외의 작업도 발주하는 경우가 자주 일어나는 것을 염두에 두어, 시스템 개발 비용의 견적 평가에 임 하여야 한다. 본 발명의 시스템 개발 작업이 수주 측과 발주 측과의 협동 작업이고, 양자가 같은 목표를 가지지 않으면 성공하기 힘들다는 점에 착안하고, 견적 평가 업무는 제공자의 개발 비용 견적을 싸게 하는 것이 아니고, 쌍방이 확인 및 납득할 수 있는 적성 비용에 대한 객관적인 근거(기준)를 나타낸 것이다.

(4) 가능한 한 정량화를 도모한다.

견적 평가 작업의 객관성을 유지하려면, 평가의 근거를 가능한 한 정량화할 필요가 있다. 특히 개수 안건에 대하여, 일반적으로 시스템 개발 비용의 60%이상을 시스템 개수에 충당하고 있음에도 불구하고, 지금까지 유효한 견적 평가 방법이 제창되어 있지 않다. 이런 실상을 감안하면, 개수 안건의 견적 평가에 주력하지 않으면, 정보 시스템 부문이 경영자나 이용 부문에의 설명 의무를 다할 수 없다. 따라서, 본 발명에서는 개수 정도를 정량화하고, 개수 안건의 견적 평가에도 확실하게 대응하고 있다.

여기서, 시스템 개발 공수 및 비용의 견적 평가에서 가장 중요한 것은, 1) 정밀도가 높은 FP값을 얻는 것, 2) 정밀도가 높은 생산성 계수를 입력할 것, 3) 명확하게 양쪽(발주 측, 수주 측)이 인식 및 합의할 수 있는 스코프(작업 범위)일 것, 4) 개수 안건의 개수율의 정량화가 가능한 것이다. 이들 4개의 요소에 관해서 끊임없는 노력으로 정밀도의 향상을 염두에 두어, 독자적인 실적 데이터를 축적하고, 견적 평가에서 적용하는 각종 계수의 정밀도 향상을 추구할 필요가 있다. 본 발명은 상기 요구를 만족시키는 것이다.

시스템 개발 비용 견적의 결과로서, 개발 비용이 산출된다. 상기 (5)식에서 산출된 개발 비용은 발주자가 스스로 견적을 낸 것으로, 이른바 평가용 표준 가격인 것이다. 이에 비해, 수주자로부터 취득한 견적은 업자 제시 가격이라고 정의되고, 평가용 표준 가격과 업자 제시 가격을 비교하여 차이의 유무를 검증하지만, 이 비교 행위가 견적의 평가가 된다.

도 11은 시스템 개발 비용의 구성을 나타내고 있고, 시스템 개발 비용으로는 하드웨어 비용, 미들웨어 및 시스템 개발 비용이 포함되지만, 본 발명에서는 그 중 시스템 개발 비용 내의 소프트웨어 개발 비용 만을 평가의 대상으로 한다. 본 발명 에 있어서 소프트웨어 개발은 SLCP의 개발 프로세스를 가리키고, 개발 프로세스의 범위는 도 12에 나타낸 바와 같다. 즉, 개발 프로세스의 범위로서는 기획 프로세스, 개발 프로세스, 운용 프로세스 및 보수 프로세스가 있고, 본 발명은 그 중 개발 프로세스를 대상으로 하고, 프로세스 개시의 준비, 시스템 요구분석, 시스템 방식 설계, 업무 상세 설계, 소프트웨어 요구 분석, 소프트웨어 방식 설계, 소프트웨어 상세 설계, 소프트웨어 코드 작성 및 테스트, 소프트웨어 결합, 소프트웨어 적합성 확인 테스트, 시스템 결합, 시스템 적합성 확인 테스트, 소프트웨어 도입, 소프트웨어 수용 지원에 대하여 평가한다. 그리고, 도 11에 있어서 안정 가동 시스템의 운영과 유지 관리 업무는, 월간 기준 근무시간이 160 hour/month(150 hour/month ~ 170 hour/month)이며, 개발 공수는 개발 프로세스 공정 작업을 대상으로 하고, 부대 작업은 개발 프로세스 공정 이외의 작업을 대상으로 하고 있다.

또, 본 발명에서는 개발 공정을 기본 설계, 상세 설계, 프로그램 디자인 및 제조, 소프트웨어 테스트, 시스템 테스트의 5 공정으로 나누어 각각의 SLCP 액티비 티와의 대응 관계는 도 13에 나타낸 바와 같다. 즉, 기본 설계로서 프로세스 개시의 준비, 시스템 요구분석, 시스템 방식 설계, 소프트웨어 요구분석 및 소프트웨어 방식 설계가 있고, 상세 설계로서 업무 상세 설계 및 소프트웨어 상세 설계가 있다. 프로그램 디자인 및 제조는 소프트웨어 코드 작성 및 테스트이며, 소프트웨어 테스트는 소프트웨어 결합 및 소프트웨어 적합성 확인 테스트이고, 시스템 테스트로서는 시스템 결합, 시스템 적합성 확인 테스트, 소프트웨어 도입 및 소프트웨어 수용 지원이 있다.

여기서, 시스템 개발 작업 중에서, 실장 공정(상세 설계 ~ 소프트웨어 테스트)이 전 개발 공수의 60%이상을 차지하고 있다. 개발 언어(코드 자동 생성 등의 중하류(middle and lower)개발 지원 툴을 포함)의 선정이 실장 공정의 작업 공정수, 비용에 큰 영향을 주고 있다. 따라서, 시스템 개발의 생산성을 설정할 때는, 개발 언어의 생산성에 유의할 필요가 있다. 개발 언어별 생산성값의 예를 도 14에 나타내지만, 본 예는 1 인월당 생산성의 전제로서, 1 인월을 160 시간으로 하고, SLCP 개발 프로세스를 작업 범위로 하고 있다. 그리고, 일부 공정 만 발주할 경우, 그 비율을 감안 하여 생산성을 조정할 필요가 있다.

전술한 개발 언어별 생산성값 이외에, 개발 생산성에 영향을 주는 요소는 많다. 예를 들면 대상 시스템의 고유 속성(규모, 시스템 구성 등), 발주 측의 요구 정도(품질 요구 정도, 문서 요구 정도 등), 수주 측의 업무 수행 능력, 성숙도(유사 시스템 구축 경험, 개발자 숙련도, 프로젝트 관리 성숙도 등), 수십 또는 백개 이상의 요소를 들 수 있다. 본 발명에서는 견적 평가의 정밀도를 유지하면서, 업 무의 간편성, 신속성을 잃지 않게 각종 비용 유발 요인 중, 시스템 개발 공수에 영향이 큰 비기능 요건(품질 요건, 기술 요건), 및 조달 측(발주 측)이 특히 중시해야 할 요소를 중심으로, 비용을 발생시키는 인자인 코스트 드라이버(cost driver)를 설정하고 있다.

이하, 각 시스템 특성이 개발 생산성에 주는 영향과 그 평가 방법을 나타낸다. 본 발명에서는, 하기 5개 항목에 계수를 부여하여 평가를 정확하게 행하도록 하고 있다.

(1) 시스템 규모: 대규모 개발의 경우, 업무간의 복잡도가 증가하고, 이해관계도 증가하기 때문에, 커뮤니케이션 오버헤드가 발생하기 쉽고, 개발 생산성이 저하된다.

(2) 시스템 환경: 플랫폼이 다르면 이용하는 OS, 미들웨어, DBMS 등도 상이하고, 거기에 따른 시스템 설계, 구축의 부하가 변화되고, 개발 생산성도 바뀐다.

(3) 처리 부하: 데이터와 프로세스의 집중 및 분산에 의해, 트랜잭션 제어, 부하 분산 등 시스템 설계 및 구축의 작업 부하가 상이하고, 개발 생산성이 변동한다.

(4) 품질 요구: 사내의 데이터 확인과 사외 서비스 요금 부과와, 품질에의 요구 정도가 상이하고, 그에 따라, 시스템 설계 관점, 리뷰/테스트/품질 평가를 어떻게 하느냐에 따라 개발 생산성이 변동된다.

(5) 문서: 대규모 개발의 경우, 본 가동 후의 운용 보수를 중시하는 경우 등, 작성하는 문서의 레벨이나 양이 바뀌어, 개발 생산성에 영향을 준다.

상기와 같은 시스템 특성에 따른 생산성 조정 계수의 예를 도 15에 나타낸다. 시스템 규모 계수는 계측 대상 어플리케이션에 의해 분류하고, 시스템 환경 계수는 시스템의 플랫폼(시스템 환경 구성)에 의해 분류하고, 처리 부하 계수는 프로세스의 형태(집중, 분산)에 의해 분류하고, 품질 요구 계수는 시스템의 품질 요구 정도(리뷰, 테스트, 품질 평가 작업)에 의해 분류하고, 문서 계수는 작성하는 문서의 종류 및 수량에 의해 분류한다. 그리고, 계수의 대소 관계는, K11 > K12 > K13 > K14 > K15이고, K21 > K22 > K23 > K24이며, K31 > K32 > K33이고, K41 > K42 > K43이며, K51 > K52 > K53이다.

개발 프로세스 전체를 일괄해서 제공 측에 발주하는 경우, 그 때의 공정별 발주율을 100%로 한다. 개발 프로세스의 일부를 자체 제작하거나, 1 안건을 복수 단계로 분할하여 발주하거나, 1 안건을 복수의 제공자에게 분할하여 발주하는 케이스를 생각할 수 있다. 이와 같은 경우, 도 16에 나타낸 바와 같은 공정별 발주율을 참고로 해서, 공정별 발주율을 설정할 필요가 있다. 또, 개발 프로세스의 모든 작업을 제공 측에 발주하는 경우(완전 외주형), 그 때의 작업 분담율을 100%로 한다. 개발 프로세스의 일부 작업을 자체 제작하거나, 1 안건을 복수의 제공자에게 분할하여 발주하거나 하는 케이스가 고려된다. 이와 같은 경우, 쌍방의 작업 분담 정도(원칙은 공수 페이스)를 감안하여, 도 17에 나타낸 바와 같은 작업 분담율을 설정할 필요가 있다. 예를 들면, 기본 설계 전작업을 15 인월로 가정하고, 그 중 운용 설계 작업(1.5 인월)을 조달 측이 담당 하고, 나머지의 13.5 인월을 제공 측이 담당한다고 한다. 이 경우, 기본 설계 공정의 제공 측 작업 분담율을

13.5인월 ÷ (1.5 인월 + 13.5 인월) × 100% = 90%…(8)

에 의해 계산되고, 90%로 한다. 다만, 아래와 같이 원래 발주 측이 담당해야 할 역할은, 여기서 작업 분담율의 대상으로 하지 않는다.

1) 사양 제시: 요구 사항의 정리, 제시 등.

2) 조달 관리: RFP 작성, 견적 평가, 업자 선정, 계약의 체결과 관리, 계약 종료에 수반하는 사무 처리 등.

3) 검수 작업: 사양, 설계, 실장 결과의 리뷰, 승인, 검증 등.

본 발명에서는, 개수 안건의 견적을 평가하는 경우, 다음과 같이 하고 있다.

1) 개수율이 100%를 넘었을 경우는, 개수율 「100%」로 한다.

2) 소프트웨어 개수 개소와 테스트 범위가 크게 상이한 경우가 있기 때문에, 개수율을 개발 개수율과 테스트 개수율로 분할한다. 그리고, 개발 개수율은 기본 설계에서부터 프로그래밍 공정에 적용하고, 테스트 개수율은 소프트웨어 테스트 공정(소프트웨어 테스트 개수율)과 시스템 테스트 공정(시스템 테스트 개수율)에 적용한다.

개수율의 산출 방법은 스텝 법을 기본으로 하고, 아래와 같이 (9)식에서 기본 설계 ~ 프로그래밍 공정에 적용한다. 행수(스텝 수)는 코멘트 행을 포함하는 물리 스텝 수이며, 모체(대상 시스템) 행수의 R1%는 변경 개소와의 인터페이스를 고려하여 계산한다. 또, 개변 행수는 기존 시스템에 대한 「추가, 변경 및 삭제」의 행수이며, 외부 부착 추가 기능은 기존 시스템은 그대로 두고, 별도 기준으로 추가하는 기능이다. 그리고, 상수 R1%, R3%및 R4%는 경험값이며, 통상 6%를 이용 하지만 개발 종류 등에 따라 변경할 수도 있다. 또, 개수 전 모체 행수는, 개수 대상 시스템(개수 대상 소프트웨어)의 기존 행수를 가리키고, 기존 시스템의 개변 행수와는 개수에 의해 개변한 행수를 가리키고, 개수 후 모체 행수와는 개수를 한 후의 대상 시스템(대상 소프트웨어)의 행수를 가리킨다. 또, R2는 변조 행수에 소프트웨어 개수 후의 변조 행수에 대한 확인 작업으로 행해지는 확인 배율을 나타내고, 통상은 개수 전 및 개수 후의 확인을 행하기 위해 2의 값을 적용한다.

개발 개수율 = {(개수 전 모체행수 × R1%) + (기존 시스템의 변조 행수 × R2) + (외부부착 추가 기능 행수)} ÷ (개수 후 모체행수)···(9)

그리고, 개수 전 모체행수 × R1%를 제1 작업 행수, 기존 시스템의 개변 행수× R2를 제2 작업 행수, 제1 작업행수, 기존 시스템의 개변 행수 및 외부 부착 추가 기능 행수의 합을 개발 작업 행수로 정의한다.

또, 스텝 방식으로 계측 곤란한 케이스의 개수율 산출 방법은, 하기 (10) 식에 따른다. (10) 식에 있어서, DET는 데이터 항목 종류(Data Element Type)를 의미하고 있다.

개발 개수율 = {(개수 전 모체 DET수 × R3%) + (추가, 변경 및 삭제 DET수)} ÷ (개수 후 모체 DET수)…(10)

그리고, 개수 전 모체 DET수 × R3%를 개수 전 작업 DET수, 추가, 변경 및 삭제 DET수를 변조 DET수, 개수 전 작업 DET수와 변조 DET수의 합을 개발 작업 DET수로 정의한다.

또한, 소프트웨어 테스트와 시스템 테스트 공정에 적용하는 테스트 공정에서 의 개수율의 산출 방법은, 아래와 같이 (11)식에 따른다. 이 경우, 신규 개발 시의 테스트 항목수 실적 데이터가 기록되어 있지 않은 경우, 소프트웨어 테스트의 기준 항목수 = FP값 × R5건, 시스템 테스트의 기준 항목수 = FP값 × R6건의 기준값을 적용하고, 테스트 개수율의 제시가 없는 경우, 개발 개수율과 동등한 것으로 간주한다. 그리고, 소프트웨어 테스트의 기준 항목수 및 시스템 테스트의 기준 항목수에 대하여, 입력 수단(110)으로부터 건수 입력을 받아들이 수도 있다. 입력을 행하지 않는 경우에는, 표준 테스트 항목 건수 테이블 기억 수단(1034)으로부터 판독되어 연산에 이용된다.

테스트 개수율 = {(개수 전 모체·신규 개발 시의 테스트 항목수 × R4%) + (개수 시의 테스트 항목수)} ÷ (개수 후 모체·신규 개발 시의 테스트 항목수) …(11)

그리고, 개수 전 모체·신규 개발 시의 테스트 항목수 × R4%를 제1 테스트 작업 행수, 제1 테스트 작업 행수와 개수 시의 테스트 항목수와의 합을 전체 테스트 작업 행수로 정의한다.

이하, 대표적인 「부대 작업」을 예시한다.

(1) 운용 테스트 관련 작업: 운용 테스트는, 이용자가 주체로 하는 본가동 환경에서의 소프트웨어, 시스템 및 업무 전체를 확인하는 테스트이다. 이것에 부수되는 환경 구축, 이용자 지원 등의 작업을 부대 작업으로 한다.

(2) 이행 관련 작업: 구 운용 형태로부터 신 운용 형태로 변환에 수반하는 업무, 시스템 및 데이터의 이행 작업을 부대 작업으로 한다. (다만, 이행용 툴의 개발은 표준 개발 작업의 범주로 하고, FP로 평가하는 방식을 채용한다.)

(3) 운용 관련 작업: 본 가동을 위한 이용자 교육 훈련 및 본 가동 작업(운용 감시, 가동 정보 수집, 개선 및 평가 등)을 부대 작업으로 한다.

(4) 개발 지원 작업: 개발 표준화(작업 순서, 템플릿(template) 및 기준)의 책정과 추진 및 품질 보증(계약, 프로세스, 요구 사항 및 문서화의 검증과 타당성 확인), 자원 관리 등을 부대 작업으로 한다.

(5) 프로젝트 관리: 진척 관리, 문제 관리, 변경 관리 등을 부대 작업으로 한다. 그리고, 본 발명에서는, 부대 작업비의 견적 평가는 WBS 정밀 조사 방식으로 행한다.

본 발명에서는 소프트웨어 개발 기술자를 도 18에 나타낸 바와 같은 4구분으로 나누어 각각의 역할과 담당을 결정하고 있다. 즉, 개발 기술자1은 기본 설계나 시스템 테스트를 주로 담당 하고, 시스템의 구성 이미지 책정의 중심적 역할, 시스템 개발 계획의 전체 구상, 프로젝트 체제의 구축, 후속 공정의 프로젝트 관리 지표 결정 등의 역할을 담당하고 있다. 개발 기술자2는 기본 설계, 상세 설계, 소프트웨어 테스트나 시스템 테스트를 주로 담당 하고, 업무의 모델화, 정보 시스템화의 계획을 책정하거나, 시스템의 기능 설계 및 시스템 구체화의 중심적 역할 등을 담당하고 있다. 또, 개발 기술자3(설계)은 상세 설계나 소프트웨어 테스트를 주로 담당하고, 시스템의 기본 설계를 기본으로 한 상세 설계 작성의 중심적 역할을 담당하고 있고, 개발 기술자4(제조)는 프로그램 디자인 및 제조를 주로 담당하고, 프로그래밍의 중심적 역할, 프로그램 모듈(module)이나 각 프로세스의 테스트를 담당 하고 있다.

도 19는 본 발명의 입력 화면의 일례를 나타내고, 도 20은 본 발명의 결과를 나타내는 표시 화면의 일례이다. 본 발명에 있어서는 신규 안건, 개수 안건 모두 평가 가능하도록 되어있고, 신규 안건과 개수 안건의 유일한 차이는, 도 20에 있어서의 항번 4)의 개수율이다. 신규 안건의 경우는 개수율이 100%가 되고, 개수 안건의 경우는 개수율이 100% 미만으로 되어 있다.

도 19의 입력 화면에서는, 제공 측으로부터 제시된 견적 가격의 고하를 평가하는 업무를 상정하고 있으므로, 제공 측 견적 비용도 입력해야 할 항목의 하나로 되어 있다. 입력 작업은 웹 화면을 스크롤하여 행한다. 「제공 측 견적 비용」의 최하단의 「부대 작업 공수」란에는 부대 작업의 수치를 입력한다.

본 발명에서는, 산출한 기능 규모(FP)와 개발비를 이용하여 도 21과 같이 견적을 평가한다. 즉, 규모가 과대나 과소의 경우, 제공자가 개발 범위를 과부족으로 파악하고 있지 않은지, FP 명세를 정밀 조사하고, 반대로 비용이 과대나 과소의 경우, 제공자가 추측한 작업 내용에 과부족은 없는지, 작업 내용을 정밀 조사한다. 도 21에서는, C안건 및 E안건이 적성 가격인 것을 나타내고 있다.

도 20의 결과 표시 화면에 있어서의 「개발 공수 비용 평가」 란은, 이용 기업이 FP법으로 산출한 개발 비용 견적과 제공 측으로부터 취득한 개발 비용 견적을 대비시켜, 제공 측 견적이 너무 높지 않는가, 또는 너무 낮지 않는가를 판단하기 위한 정보가 표시된다.

본 발명은 인터넷을 이용한 네트워크에 있어서도 이용 가능하다.

본 발명에 의하면, 비교적 간이 시스템이면서, 소프트웨어 개발 공수 비용의 개발이나 환경을 고려한 요소를 평가 조건으로서 합리적으로 입력하고 있으므로, 소프트웨어 개발 공수 비용의 평가를 객관적이며 공정한 방법으로 행할 수 있다. 또, 본 발명에 의하면, 신규 조건뿐만 아니라, 개수 안건에 대해서도 소프트웨어 기능 규모의 정량화를 통해서 견적 가격의 불확실한 부분을 배제할 수 있고, 평가의 합리성, 타당성 및 투명성을 높일 수 있다.

본 발명에 의하면, FP를 기본으로 하여 시스템의 개발 상황이나 환경을 고려하여 요소를 조건으로서 평가하고 있으므로, 소프트웨어 개발 공수 비용의 평가를 객관적이며 또한 공정하게 행할 수 있고, 그러므로 소프트웨어 시장(입찰이나 판매 등)에 있어서 견적의 불확실성을 확실하게 배제할 수 있고, 소프트웨어 산업의 활성화를 도모할 수 있다.

Claims (8)

1. 소프트웨어의 기능 규모를 나타내는 기능 포인트(function point)값을 기본으로 하여, 평가 대상인 소프트웨어의 개발 상황 및 시스템 환경을 고려한 평가 요소에 따라서 상기 기능 포인트값에 가중을 두고, 상기 소프트웨어의 개발 공수/비용을 평가하는 평가 장치로서,

   소프트웨어의 일인당 월 개발 언어별 생산성을 정량화한 생산성값을 기억하는 개발 언어별 생산성값 테이블과,

   상기 생산값을 조정하는 계수로서, 시스템 규모를 상기 기능 포인트값의 양에 따라 분류하여 정량화한 시스템 규모 계수, 및 시스템 환경을 그 형태에 따라 분류해서 정량화한 시스템 환경 계수를 포함하는 각 계수를 기억하는 생산성 조정 계수 테이블과,

   소프트웨어 개발 언어와 그 이용 비율, 상기 시스템 환경의 분류 항목, 상기 시스템 규모의 분류 항목, 시스템 엔지니어 단가 금액을 포함하는 정보의 입력 화면을 표시하는 표시 수단과,

   상기 입력 화면 상에서, 선택된 상기 개발 언어를 기초로, 상기 개발 언어 별 생산성값 테이블에서 얻은 상기 소프트웨어의 개발 언어에 대응하는 상기 생산성값, 및 상기 입력 화면 상에서 입력된 상기 이용 비율에 따라서, 소프트웨어 언어를 평가 요소로 한 소프트웨어 개발 언어별 생산성값을 산출하는 수단과,

   상기 입력 화면 상에서, 선택된 상기 시스템 규모의 항목 및 상기 시스템 환 경의 항목을 포함하는 각 항목에 대응하는 계수를 상기 생산성 계수 테이블에서 얻고, 이들 계수를 생산성 조정 계수로서 설정하는 수단과,

   상기 소프트웨어의 기본 설계, 상세 설계, 프로그램 설계 및 제조, 소프트웨어 테스트 및 시스템 테스트의 각 공정에 있어서의 상기 개발 언어별 생산성값 및 상기 생산성 조정 계수, 및 상기 각 공정에 있어서의 공정별 발주율, 상기 소프트웨어의 발주 측과 수주 측과의 작업 비율을 나타내는 작업 분담율 및 기존 시스템에 대한 개수(改修) 비율을 나타내는 개수율의 입력 정보에 따라서 상기 소프트웨어의 생산성 계수를 산출하는 수단과,

   상기 각 공정에 있어서의 상기 기능 포인트값을 상기 생산성 계수로 나누어 상기 소프트웨어의 표준 개발 작업 공수(工數; manpower)를 산정하는 개발 공수 산정 수단과,

   상기 표준 개발 작업 공수, 및 상기 시스템 엔지니어 단가 금액의 입력 정보에 따라서 상기 소프트웨어의 개발 비용을 산정하는 개발 비용 산정 수단과,

   상기 개발 공수 산정 수단에 의해 산정한 상기 표준 개발 작업 공수, 및 상기 개발 비용 산정 수단에 의해 산정한 상기 개발 비용을 상기 소프트웨어의 개발 공수/비용의 평가 정보로서 출력하는 평가 정보 출력 수단

   을 구비한 것을 특징으로 하는 소프트웨어 개발 공수 비용의 평가 장치.
2. 제1항에 있어서,

   상기 평가 요소로서 업자 제시 가격을 포함하고,

   상기 평가 정보 출력 수단은, 상기 개발 비용 산정 수단에 의해 산정한 상기 개발 비용을 평가용 기준 가격으로서, 그 평가용 기준 가격과 상기 입력 화면 상에서 입력된 상기 업자 제시 가격을 비교한 정보를 출력하는 것을 특징으로 하는 소프트웨어 개발 공수 비용의 평가 장치.
3. 제1항 또는 제2항에 있어서,

   상기 평가 정보 출력 수단은, 상기 표준 개발 작업 공수의 합계 및 상기 개발 비용의 합계를 출력하고, 상기 표준 개발 작업 공수 및 상기 개발 비용을 상기 공정별로 출력하는 것을 특징으로 하는 개발 공수 비용의 평가 장치.
4. 제1항 내지 제3항 중 어느 한 항에 있어서,

   상기 생산성 조정 계수 테이블에는, 데이터와 프로세스의 집중 처리 및 분산 처리를 포함하는 처리 형태에 따른 개발 작업 부하를 상기 처리 형태에 따라 분류하여 정형화한 처리 부하 계수, 이용자로부터의 품질 요구를 그 요구 정도에 따라 분류해서 정량화한 품질 요구 계수, 및 문서에 관한 생산성을 문서의 종류, 수량에 의해 분류하여 정량화한 문서 계수가 추가로 기억되어 있고,

   상기 표시 수단은, 상기 처리 부하 계수의 분류 항목, 상기 품질 요구 계수의 분류 항목 및 상기 문서 계수의 분류 항목의 각 선택 메뉴를 상기 입력 화면에 표시하고,

   상기 생산성 조정 계수를 산출하는 수단은, 상기 각 선택 메뉴 중에서 선택 된 상기 처리 부하 계수의 항목, 상기 품질 요구 계수의 항목 및 상기 문서 계수의 항목에 각각 대응하는 상기 처리 부하 계수, 상기 품질 요구 계수 및 상기 문서 계수를 상기 생산성 조정 계수 테이블에서 얻고, 상기 계수들, 상기 시스템 규모 계수, 및 상기 시스템 환경 계수에 따라서 상기 생산성 조정 계수를 산출하는 것을 특징으로 하는 소프트웨어 개발 공수 비용의 평가 장치.
5. 제1항 내지 제4항 중 어느 한 항에 있어서,

   상기 각 공정별로 설정된 표준 발주율을 기억하는 개발 공정별 표준 배분율 테이블을 구비하고, 상기 생산성 계수를 산출하는 수단은, 상기 공정별 발주율이 입력되어 있지 않은 경우에는, 입력되지 않은 공정에 대응하는 상기 표준 발주율을 상기 개발 공정별 표준 배분율 테이블에서 얻고, 상기 표준 발주율을 항기 공정에 있어서 상기 공정별 발주율로 하여 상기 생산성 계수를 산출하는 것을 특징으로 하는 소프트웨어 개발 공수 비용의 평가 장치.
6. 제1항 내지 제5항 중 어느 한 항에 있어서,

   상기 소프트웨어가 신규 개발인 경우, 상기 개수율(改修率)을 100%로 하여 상기 소프트웨어의 생산성 계수가 산출되는 것을 특징으로 하는 소프트웨어 개발 공수 비용의 평가 장치.
7. 제1항 내지 제6항 중 어느 한 항에 있어서,

   상기 평가 요소로서, 상기 소프트웨어의 표준 개발 작업 이외에 발주자로부터 제공자에게 위탁된 작업의 공수를 나타내는 부대(附帶) 작업 공정을 포함하고,

   상기 개발 비용 산정 수단은, 상기 표준 개발 작업 공수와 상기 부대 작업 공수의 합에 상기 시스템 엔지니어 단가 금액을 곱해서 상기 개발 비용을 산정하는 것을 특징으로 하는 소프트웨어 개발 공수 비용의 평가 장치.
8. 제1항 내지 제7항 중 어느 한 항에 있어서,

   상기 기능 포인트값은, IFPUG(International Function Point Users Group)법, 개산법(槪算法), 논리 파일 추정법 또는 스텝 산정법 중 어느 하나의 방법을 이용하여 산출한 기능 포인트값인 것을 특징으로 하는 소프트웨어 개발 공수 비용의 평가 장치.

Images