정보시스템 원가산정

정보시스템 원가산정

 

제 1 장 개요

 

1.1 연구 배경 및 목적

 

21세기 지식기반국가 건설을 기치로 삼고있는 우리나라에서 소프트웨어 산업을 기반으로 하는 정보산업 발달을 위하여 정부와 관련 업체들이 총력을 기울이고 있는 상황에 있다. 소프트웨어 산업을 중심으로 하는 정보산업은 국가 정보화 촉진을 위한 핵심산업이자 국가 경쟁력 강화를 위한 전략산업으로 그 중요성이 부각되어 있다.

이러한 정보산업계에서의 정보시스템 비용 산정방법으로 적용되고 있는 소프트웨어 사업대가의 기준(정보통신부 고시)은 우리나라 정보시스템 원가계산 시장에서 원칙으로 적용되고 있다. 정보시스템 원가계산에 대한 수요가 증가하고 있는 현 시장 상황에서 원가계산에 대한 제도 및 지침이 부족한 현실이다.

 

향후 정보시스템 원가감리의 발전과 정보시스템 원가계산 수요의 증대에 대비하여 제도 및 지침 연구에 앞서 본 연구를 시행함으로 원가감리를 위한 체계 수립 개시의 의미가 있는 것이다. 정보기술 측면에서의 정보시스템감리에서 그 범위를 확대하여, 최근에 수요가 늘어나고 있는 정보시스템 원가계산과 원가감리의 활성화를 기대하며, 제도적인 체계 및 기술적인 지침을 제시하는 기초작업으로 본 연구를 시행한다.

 

1.2 연구 내용

원가계산에는 제품의 원가계산, 서비스(무형제품)의 원가계산 등이 존재한다. 정보시스템 원가계산의 성격은 정보시스템을 소프트웨어(application) 중심으로 볼 때 서비스의 원가계산 범주의 성격이 강한 것으로 볼 수 있다.

정보시스템 구축에서 장비의 도입은 투자금액적으로 상당량의 비중을 차지하고 있지만 서비스를 구현하기 위한 준비단계(원재료비 성격)이고, 소프트웨어 구현을 통한 사용자 지향의 서비스가 중심이 되는 것이다.

 

정보시스템의 원가계산 구성을

1) 장비(hardware) 도입비용,

2) 소프트웨어 구축비용,

3) 시스템 소프트웨어(패키지) 도입비용,

4) 시스템 운영(유지보수)비용 등의 네 가지로 구분 설명하며, 원가계산 수행사례를 바탕으로 정보시스템 원가계산 방식, 절차 등을 설명하고자 한다.

정보시스템의 원가계산에서 소프트웨어 비용산정/예측 기법인 COCOMO , 소프트웨어 원가계산 프로세스, Function Point 모델을 기반으로 한 Cost Estimation 등의 이론과 사례를 접목시켜보려 시도하고, 각 방안에서 제시하고 있는 원가산정요소의 분석을 시도해 보고자 한다.

 

여러 소프트웨어 비용산정/예측기법들에서 분석된 원가산정요소를 비교하여 공통적으로 제시되고 있는 요소들을 파악하고, 전체 소프트웨어 비용에 영향을 주는 요소들의 중요성 분석을 시도한다. 또, 소프트웨어의 품질을 유지하면서 정보시스템 비용을 절감할 수 있는 방안으로, 주요한 원가산정요소를 발굴하여 영향요인 조정을 통하여 적정한 정보시스템 원가를 유지하는 방안을 정보화사업 추진사례연구를 통하여 제시해 본다.

 

 

제 2 장 정보시스템의 원가계산 구성

정보시스템의 원가계산은 시스템 운용장비의 구입비용, 소프트웨어(application) 구축비용, 소프트웨어(패키지) 구입비용, 정보시스템 운영(유지보수)을 위한 비용 등으로 분류하여 볼 수 있다. 분류별로 원가계산의 수행방법을 실무적으로 간략히 설명해 보고자 한다.

 

2.1 장비(hardware) 도입비용

시스템 구축을 위한 장비 도입에 대한 사전 원가의 산정은 공급업체들의 견적가격에 의존하는 경향이 있다. 원가계산 대상사업의 제안요청서 또는 과업내용서의 장비내역, 요구 성능 등을 참조하여 2개 이상의 업체를 선정하여 견적가격을 받는다. 업체로부터 제출된 견적서의 상세내역이 업체별로 동일하고, 제안요청서 또는 과업내용서의 장비내역, 요구 성능 등을 만족하는 경우 저가 견적업체의 제품가격을 원가로 선정할 수 있다. 그러나, 요구 성능과 동일하지 않거나, 업체로부터 제출된 견적서의 상세내역(장비의 구성)이 업체별로 또는 장비별로 상이한 부분이 존재할 경우가 많아 융통성 있게 적용하는 원가산정 기법이 필요하다고 생각된다. 제출된 견적서의 상세내역이 업체별로 또는 장비별로 상이한 부분이 존재할 경우 최저가격으로 선정하는 것에는 불합리한 점이 있으므로 그 평균가격으로 사전원가를 산정하는 사례도 볼 수 있다.

 

2.2 시스템 구축비용

시스템 구축비용은 과학기술부공고 ‘엔지니어링사업대가의 기준’과 정보통신부고시 ‘소프트웨어 사업대가기준’ 등을 기반으로 계산하고 있는 추세이다.

 

2.2.1 소프트웨어 개발비

소프트웨어 사업대가기준을 따르면 개발공정별 소프트웨어 개발생산성 기준표를 근거로 산출한 스텝당 인건비 단가에 보정계수를 반영하고, 총 스텝수를 곱하여 개발비를 산정하는 물량기준 방식을 채용하고 있으며, 그 산정절차는 다음과 같다.

1) 스텝수 방식, 본수 방식, 기능점수 방식에 의하여 개발대상 소프트웨어의 총 스텝수를 산출한다. 프로그램 수행을 위한 실행문, 환경선언, 데이터선언 등을 포함하는 스텝들로 주스텝수와 부스텝수를 구분하지 않고, 프로그램의 실제 수행에 필요한 부분을 모두 스텝수로 정의한다. 기능점수 방식으로 산정하고자 할 경우에는 계산된 총기능점수에 80을 곱하여 총 스텝수를 산출한다.

          2) 총 스텝수에 공정별 스텝당 인건비 단가를 곱하여 기초인건비를 산출한다.

3) 기초인건비에 규모별 보정계수, 프로젝트 형태별 보정계수, 적용대상 기종별 보정계수, 개발언어별 보정계수를 곱하여 직접인건비를 산출한다. 단, 개발언어별 보정계수는 소프트웨어 개발 공정중 프로그램 작성 이후의 공정에만 적용한다. 인적지원방식에 의한 소프트웨어 개발비 산정의 경우, 직접인건비는 계약에 의해 지원되는 전문인력의 등급별로 지원기간에 따라 소프트웨어 기술자 노임단가를 적용하여 산정함을 원칙으로 한다. 단, 지원기간이 공휴일을 포함하여 1개월 미만일 경우는 투입일수를 30일로 나누어 일할계산한다.

4) 직접인건비에 제경비율을 곱하여 제경비를 산정하고, 직접인건비와 제경비를 합한 비용에 기술요율을 곱하여 기술료를 산정한다.

5) 소프트웨어 개발에 개략적으로 필요한 직접경비 항목을 도출하여 직접경비를 산정한다.

6) 소프트웨어 개발비 총액은 직접인건비, 직접경비, 제경비 및 기술료의 합으로 계산된다.

 

2.2.2 시스템 운용환경 구축비

시스템 운용환경구축비의 산정은 엔지니어링사업대가의 기준 제8조의 기본설계, 실시설계의 내용을 기본으로 하고, 정보시스템 환경 구축의 특성을 반영하여 산정한다.

 

1) 개발한 시스템의 운용을 위한 시스템 운용환경 구축비를 산정한다.

2) Host 중심의 Main Frame체제, Client/Server체제 등과 응용업무의 특성을 고려하여 시스템 플랫폼이 구성된다. 이러한 시스템 환경 구축의 특성에 따라 플랫폼 및 네트워크 구축의 기본설계, 실시설계의 범위로 나누어 산정할 수 있고, 공사비(시스템 운용환경 조성비)도 고려하여 산정할 수 있다.

3) 시스템 운용환경 구축비는 시스템 운용환경 조성비와 설계(기본설계, 실시설계)비 등의 합으로 계산된다.

 

2.2.3 데이터베이스 구축비

정보시스템에서 소프트웨어, 하드웨어, 네트워크에 이어 데이터베이스 구축의 중요성이 높아지고 있다. 최근 데이터베이스 구축사업에 대한 사업비 계산의 소요가 증가한 상황이며, 특히 멀티미디어 데이터 입력을 통한 데이터베이스 구축의 적정한 원가 산정방법에 대한 추가적인 연구가 필요한 실정이다.

1) 데이터베이스 구축비는 데이터베이스 구축에 필요한 소프트웨어 개발비와 데이터베이스 설계비, 데이터 제작비 등으로 구분하고 있다.

2) 데이터베이스 설계비와 데이터제작비, 미디어(문자, 이미지, 그래픽, 에니메이션, 동영상, 음성, 음향, 음악)별 기준데이터별 인건비 및 경비 산정기준을 이용하여 데이터베이스 구축비를 계산한다.

3) 데이터베이스 구축비는 데이터베이스 구축에 필요한 소프트웨어개발비, 데이터베이스 설계비, 직접경비(데이터제작비) 등의 합으로 계산된다.

 

2.2.4 자료입력비

데이터베이스 구축 또는 특정 어플리케이션 처리를 위한 다량의 자료입력 필요성이 있을 경우, 특성있는 미디어와 많은 인력의 투입 또는 다양한 입력장치의 사용이 필요하게 된다. 자료입력비는 자료입력 소요공수와 이를 반영하여 인건비를 산정하는 방식을 주로 사용하고 있다.

1) 기본적으로 자료입력에 소요되는 인력(컴퓨터 S/W 기사, 자료입력원)의 소요공수를 기초하여 산정한다.

2) 자료입력비는 인건비, 제경비, 이윤 등의 합으로 산정된다.

 

2.2.5 정보전략계획 수립비

정보전략계획 수립의 중요성의 인식이 확산되는 가운데, 정보전략계획 수립 프로젝트 수행 계약을 위한 사전 비용산정의 필요성도 증가하고 있다. 정보전략계획 수립비는 정보전략계획 업무범위의 설정과 업무의 난이도를 반영하여 계산하게 된다.

          1) 정보시스템 개발 이전에 전사 차원에서 정보전략계획 수립을 위한 비용 산출

2) 조직의 규모나 계획 수립 범위를 기준으로 컨설팅 지수를 산정하고 그 지수에 따라 대가를 산정하는 방식을 취하고 있다.

 

2.3 시스템 소프트웨어(패키지) 도입비용

시스템 개발 또는 구축에 필요한 소프트웨어 구입에 대한 사전 원가의 산정은 공급업체들의 견적가격에 의하여 계산하는 경향이 있다. 원가계산 대상사업의 제안요청서 또는 과업내용서의 소프트웨어 내역, 요구 기능․성능 등을 참조하여 2개 이상의 업체를 선정하여 견적가격을 받는다. 업체로부터 제출된 견적서의 상세내역이 업체별로 동일하고, 제안요청서 또는 과업내용서의 소프트웨어 내역, 요구 기능․성능 등을 만족하는 경우 저가 견적업체의 제품가격을 원가로 선정할 수 있다. 그러나, 요구 기능․성능과 동일하지 않거나, 업체로부터 제출된 견적서의 상세내역(부품 소프트웨어)이 업체별로 또는 소프트웨어 패키지별로 상이한 부분이 존재할 경우 융통성 있게 적용하는 원가산정 기법이 필요하다고 생각된다.

제출된 견적서의 상세내역이 업체별로 또는 소프트웨어별로 상이한 부분이 존재할 경우 최저가격으로 선정하는 것에는 불합리한 점이 있으므로 그 평균가격으로 사전원가를 산정하는 사례를 볼 수 있다.

 

2.4 시스템 운영(유지보수)비용

 

2.4.1 소프트웨어의 유지보수 수행형태

소프트웨어의 유지보수 수행형태는 자체유지보수와 용역유지보수로 구분된다. 자체유지보수란 개발이 완료된 소프트웨어(응용시스템)를 발주자가 자체적으로 유지보수하는 것을 말한다. 용역유지보수란 소프트웨어 사업자에게 용역을 주어 소프트웨어를 관리하는 것을 말한다. 여기에서 주로 원가계산 대상이 되는 분야는 용역유지보수부문이다.

 

2.4.2. 용역유지보수 대가산정

2000소프트웨어 사업대가기준에 의하면, 연간 소프트웨어 용역유지보수의 대가는 유지보수 계약시점에서의 소프트웨어 개발비 산정가의 10~15% 범위내에서 다음 [표 2.4.1] 용역유지보수대가 산정기준에 따라 산정한다. 유지보수 계약시점 기준의 소프트웨어 ‘개발비’는, 최초 소프트웨어 개발시점의 개발비가 아닌 유지보수 계약시점의 현재가치로 산출한 개발비를 의미한다.

유지보수 대상 시스템의 특성

단 순

보 통

복 잡

기준(년간)

점 수

기준(년간)

점 수

기준(년간)

점 수

유지보수 횟수

4회 이하

0

12회 이하

20

12회 초과

35

자료처리 건수

10회 미만

0

10-50만

10

50만 초과

25

타시스템 연계

없음

0

1-2시스템

5

3개 이상

10

실무지식 필요

별도지식 불필요

0

기초지식 이해필요

5

전문실무 능력필요

10

분산처리 여부

실시않음

0

통합하의 분산처리0

10

순수분산

처리

20

 

※ 1. 유지보수 대상시스템의 특성별로 단순, 보통, 복잡성을 판정하여 총점수(TMP) 계산

2. 유지보수 난이도 (%) = 10 + 5 × TMP / 100

3. 유지보수 대가 = 유지보수 난이도 (%) × 소프트웨어 개발비 산정가

유지보수업무의 대가를 산정할 때 투입되는 인력을 계산하여 인적지원 방식에 의한 대가를 산정하는 방식도 사용할 수 있다. 인적지원방식에 의한 유지보수용역 대가 산정의 경우, 직접인건비는 계약에 의해 지원되는 전문인력의 등급별로 지원기간에 따라 소프트웨어 기술자 노임단가를 적용하여 산정함을 원칙으로 한다. 현실에서는 유지보수 업무별, 기간별로 투입되는 인력의 크기를 파악하고, 투입되는 인력의 기술자등급 구분별로 지원기간에 따라 소프트웨어 기술자 노임단가를 적용하여 산정하는 방법이 수월하게 사용되는 경향으로 보인다.

 

 

제 3 장 소프트웨어 원가 산정 프로세스

 

3.1 소프트웨어 원가의 구성요소

소프트웨어 원가(software cost)란 소프트웨어 개발과 관련된 금액을 직접적으로 의미하는 것은 아니며, 소프트웨어 개발과 관련한 직접적인 금액을 산출하는 것은 실질적으로 불가능하고 항상 의미가 있는 것도 아니다. 그 보다 관심이 있는 내용은 얼마의 노력이 요구되는가 또는 얼마의 기간이 필요한가 등이다. 필요한 노력이나 기간은 금액으로도 변환될 수 있을 것이다. 소프트웨어 원가는 결국 다음과 같은 세 가지 항목을 추정하고자 하는 것이다([6]).

∙투입인원(manpower loading) : 시간의 함수로 표현된 프로젝트에 투입될 엔지니어와 관리자의 수.

∙노력(effort) : 프로젝트를 완료하기 위해 필요한 공학적/관리적 노력을 의미하고 보통 월간투입 인원으로 측정된다. 인력의 형태와 숙련도 등에 영향을 받는다.

∙기간(duration) : 프로젝트를 완성하는 데 필요한 시간. 보통 개월 수로 측정된다.

 

소프트웨어 원가 산정 프로세스(software cost estimation process)는 소프트웨어 원가 추정치(software cost estimate)를 얻기 위해 조직이 사용하는 방법(technique)과 일련의 절차(procedure)들을 말한다. 시스템 요구사항 등이 소프트웨어 원가 산정 프로세스의 입력이 되고, 출력은 필요한 노력/투입인원/기간 등이 된다. 소프트웨어 원가 추정 프로세스는 조직의 소프트웨어 개발이 이루어지는 방식에 따라 달라지게 되는데, 소프트웨어 프로세스(software process)는 소프트웨어 개발 프로젝트를 계획/관리/통제하기 위해 사용되는 절차/기법/표준들을 말한다. 또한, 소프트웨어 프로세스는 원가 산정의 목적/시기/방법들을 정하고 있다. 원가 산정을 하는 목적에는 여러 가지가 있으나 다음 세 가지가 원가 산정의 가장 흔한 목적이라 할 수 있다([6]).

∙계획/예산편성: 경영자는 소프트웨어 원가 추정치에 근거하여 사업의 진행 여부와 입찰가격 결정 등의 전략적 의사 결정을 내린다.

∙사업관리: 프로젝트 관리자는 프로젝트 구현을 계획/감독/통제하는 데 원가추정치를 사용한다.

∙프로젝트 구성원간의 의사소통: 보통 원가 추정치는 프로젝트의 완전한 작업분할구조(work breakdown structure)를 포함하고 있어 이를 기초로 하여 프로젝트 구성원들이 자신의 역할을 이해하게 된다.

 

소프트웨어 원가를 산정하는 목적에 따라 원가 산정 프로세스의 출력과 정확도가 달라진다. 관리자가 사업 타당성 분석을 통해 사업의 진행 여부를 결정하기 위해서는 필요한 노력에 대한 개략적인 추정치만 있으면 되지만, 프로젝트 일정 계획을 수립하기 위해서는 보다 정확하고 세부적인 추정치가 필요하게 된다.

 

소프트웨어 원가 산정과 재산정(re-estimate)은 개발 프로세스 내내 수행되는데, 소프트웨어 프로세스는 이러한 원가 산정과 재산정이 수행되어야 할 시기를 정의한다. 원가 재산정은 다양한 목적에 의해 수행되는데, 첫 번째는 추정치가 근사적인 경우가 있으므로 작업에 대한 새로운 정보가 알려질 때 추정치의 정확성을 향상시키기 위해 수행된다. 또한, 재산정은 이전 추정치보다 보다 상세한 정보가 요구되는 경우에 수행되기도 한다.

 

3.2 소프트웨어 원가 산정 프로세스 현황

조직마다 원가 추정치를 얻기 위해 다양한 기법과 접근방법을 사용한다. 이러한 다양한 기법과 접근방법들을 이해하고 비교하기 위해서는 먼저 원가 산정 프로세스의 기본 모델을 세울 필요가 있다. 소프트웨어 원가 산정 프로세스 모델을 다음과 같은 세 가지 관점에서 각 질문의 대답을 통해 살펴보는 것이 유용할 것이다([6]).

∙원가 추정과 소프트웨어 프로세스: 소프트웨어 프로세스에서 원가 추정의 역할은 무엇인가?

∙소프트웨어 프로세스의 입력과 출력: 원가 추정을 수행하는데 획득 가능한 데이터는 무엇이고 어떤 정보를 생성해내야 하는가?

∙프로세스: 추정치를 생성하기 위해 획득 가능한 데이터를 어떻게 사용하는가?

 

① 원가 산정과 소프트웨어 프로세스

여러 가지 목적에 의해 프로젝트의 원가산정이 수행된다. 앞에서 언급했듯이 원가산정의 목적은 원가 추정 시기와 방법을 결정하는 중요한 요소가 된다. 원가 산정의 목적은 사업의 승인, 사업의 관리, 프로젝트 구성원간의 의사소통 등 크게 세 가지로 요약될 수 있다. 사업승인(project approval)의 목적으로 사용되는 경우, 원가 산정은 프로젝트 수명 주기의 맨 초기 단계에 수행되어야 하고, 흔히 요구사항이 명세되기 이전에 수행된다. 사업승인 프로세스에는 사업 수행여부를 결정하는 여러 가지 항목들이 있고, 각각의 항목들에 대해 관리자가 의사결정을 내리기 위해서는 원가 추정치를 필요로 한다. 프로젝트 초기 단계에는 프로젝트 수행 여부를 결정하는 데 충분할 정도의 대략적인 추정치만 필요하지만, 프로젝트가 진행됨에 따라 프로젝트 중단 여부를 결정하기 위해서는 프로젝트 종료까지의 상세한 원가 추정치를 필요로 한다.

프로젝트의 관리와 이해를 위해, 원가 추정치는 현재까지의 정보와 상태를 반영할 수 있도록 주기적으로 갱신되어야 하므로, 원가의 재산정은 원가 산정의 목적에 상관없이 프로젝트 개발수명주기 내내 수행될 필요가 있다. 프로젝트가 진행됨에 따라 제품 및 프로세스에 대한 정보가 보다 많이 획득되므로 이러한 정보는 원가 추정치의 정확성을 향상시키는 데 사용될 수 있을 것이다.

 

② 원가 산정 프로세스의 입력/출력

소프트웨어 원가 산정 프로세스의 입력은 원가 산정이 수행되는 시기에 따라 달라진다. 사업의 초기 단계의 추정치는 희소하고 불완전한 정보에 의존한다. 요구사항과 시스템 구조가 확정되기 전에 수행되는 산정도 개략적인 자료에 의존하기 때문에 정확성이 높지 않다. 하지만, 개발 주기의 후반부에 수행되는 추정치는 보다 폭넓은 정보에 의존하고 있으며 많은 사업 또는 프로세스에 관한 정보 등을 이용한다. 일반적으로 보다 많은 정보를 획득할수록 보다 정확한 추정치를 얻을 수 있을 것이다.

 

대부분의 원가산정 모형은 원가산정 프로세스를 원가요소(cost driver)들의 함수로 규정한다. 원가요소는 제품의 최종비용을 결정짓는 시스템의 특성들로 가정되는데, 가장 널리 사용되는 원가산정 기법인 COCOMO에서는 가장 주요한 원가요소를 소프트웨어에 대한 사용자 요구사항이라고 가정한다. 이러한 원가산정 프로세스에서는 요구사항이 주요 입력이 되고 원가 추정치의 근거가 된다. 원가 추정치는 다른 원가요소에 따라 보정되어 최종 원가 추정치가 계산된다.

 

실제 사업에서 소프트웨어 원가산정 프로세스는 위의 개략적인 그림보다 훨씬 복잡한 양상을 띤다. 원가계산에 사용되는 많은 정보들이 서로 상관관계를 갖고 있으므로, 원가산정 프로세스를 단순히 요구사항의 함수로 보는 것보다는 일정한 제약조건을 만족하는 프로세스로 보는 것이 정확할 수도 있다([6]). 이 때, 원가산정 프로세스의 입력은 요구사항, 소프트웨어 구조(software architecture), 가용자금 등의 제약사항들이 되고 출력은 이러한 제약조건을 만족하는 원가추정치가 된다. 이러한 관점은 원가요소에 제약이 주어지는 것을 허용하는데, 이러한 원가요소에는 납기, 소프트웨어 프로세스 등이 포함될 수 있다.

 

요구사항은 반드시 만족되어야 할 제약사항으로 원가산정과정에서 모순되거나 모호한 점들이 흔히 발견된다. 모호한 요구사항은 새로운 제약을 도입함으로써 일부 해결되기도 하지만 그대로 남아 원가추정치의 정확성에 영향을 줄 수도 있다. 또한, 재정적인 제약, 납기제약, 투입인력 제약 등은 프로젝트에 할당될 수 있는 자원에 제한을 주게 된다. 만약 프로젝트에 투입할 수 있는 자금이 한정되어 있다면, 소프트웨어의 기능의 변경에 의해서라도 원가추정치는 이러한 재정적 제약을 만족시켜야 할 것이다.

 

원가산정 프로세스에 반드시 포함되어야 할 다른 요소로는 프로젝트와 관련된 위험들이 있다. 예를 들어, 외부공급자에 대한 의존도, 새로운 CASE 도구의 적용, 해당 분야에 대한 전문성 부족 등이 프로젝트와 관련된 위험요소들이다. 이러한 위험요소들은 가능한 한 조기에 식별되어 의사결정과정과 사업관리과정에 포함될 수 있어야 한다.

 

③ 원가 산정 프로세스

식별된 제약조건을 가지고 원가산정 프로세스를 적용시켜 제약조건을 모두 만족하는 원가 추정치를 얻게 된다. 원가산정에 사용되는 기법은 조직마다 달라지지만, 크게 모형에 기반한 원가산정 프로세스와 유추에 기반한 원가산정 프로세스로 구분할 수 있다.

모형에 기반한 원가산정 프로세스에서는 시스템 특성, 사용될 소프트웨어 프로세스, 개발환경 등에 기초하여 시스템 개발 원가 산정 모형을 세운다. 원가 산정 모형은 정형화된 수학적 모형일수도 있고 원가산정에 사용되는 비정형화된 지침이 될 수도 있다.

비정형화된 모형은 기존 프로젝트에 참여함으로써 시스템 개발에 대한 상당한 경험과 지식을 보유한 숙련된 개발자들에 의해 작성된 경험적 규칙들로 이루어진다. 이러한 경험적 규칙들에는 정확한 근거와 적용방법 등이 결여되는 경우가 많다.

 

정형화된 모형은 원가산정 프로세스의 모든 입력을 정량화한 다음 입력과 출력간의 관계를 나타내는 관계식을 적용하여 추정치를 계산한다. 입력과 출력간의 관계식은 과거의 자료의 분석을 통해 개발되고 각각의 프로젝트의 환경에 맞게 조정된다. 가장 잘 알려진 모형으로 Bohem의 COCOMO, Albrecht의 기능점수(function point)방법, Putnam의 Rayleigh 곡선 적용 기법 등이 있다. 정형화된 모형에서는 요구사항을 소스코드 행수(Source Lines of Code, SLOC) 또는 기능점수(Function Point, FP) 등의 시스템 규모의 척도로 변환한다. 또한, 다른 비용요소로 제품의 복잡도(product complexity), 요구되는 신뢰성(reliability), 기억용량제약(memory constraint), 프로그램언어 경험도(program language experience) 등을 정량화하여 초기 추정치를 조정한다.

 

유추에 기반한 원가 산정 프로세스에서는 조직이 수행한 과거의 개발 프로젝트와 비교하여 현재 개발 프로젝트의 원가를 추정한다. 유추에 기반한 기법은 과거의 수행한 프로젝트에 대한 기록의 유지와 갱신을 필요로 한다. 과거의 유사한 프로젝트의 비용이 산정하고자 하는 프로젝트 원가의 기초가 된다. 과거 프로젝트에 대한 기록은 전산화되어 DB에 저장될 수 있고, 상세한 특성과 관련 정보가 함께 저장되어 검색되기도 한다.

 

3.3 소프트웨어 원가 산정시 문제점

조직마다 소프트웨어 원가 추정치의 정확성에 차이가 있기는 하지만 정확한 소프트웨어 원가를 계산하는 것은 쉽지 않다. 더군다나 확실한 자료 없이는 실제 소요된 비용이 초기 원가 추정치에 얼마나 근접했는지를 검증할 수도 없고, 개발된 시스템이 요구사항과 사용자 기대수준을 만족했는가를 검증하기도 쉽지 않다. Vidger & Kark[6]는 소프트웨어 원가 산정을 어렵게 하는 이유로 다음과 같은 7 가지를 제시하였다.

 

① 요구사항과 관련된 문제점

거의 대부분의 조직에서 원가 추정치가 부정확한 이유로 요구사항과 관련된 문제점을 지적하는데, 이는 조직의 규모나 특성, 역할 등에 상관없이 공통적으로 적용된다. 요구사항과 관련된 문제점으로는 요구사항의 불완전성/모호성/부정확성/불가해성 등을 들 수 있다.

요구사항과 관련된 첫 번째 문제점은 사용자가 사업 초기 단계에 요구사항을 정확하게 이해하지 못하는 경향이 있다는 것이다. 보통 기존 시스템에 문제점이 발견되고 문제점에 대한 명확한 인식과 해결책이 정리되지 않은 시점에서 소프트웨어 프로젝트가 시작되므로, 정확한 원가 추정치를 계산해 낼 수 있을 만큼 상세한 수준의 요구사항 규격을 기술하는 것은 거의 불가능하다. 따라서, 사업 초기 단계에서 이루어지는 원가 산정은 부정확할 수밖에 없다. 이러한 요구사항에 대한 명확한 이해의 부족은 시스템 종류나 프로젝트 유형에 상관없이 공통적으로 적용된다. 개발 프로젝트의 경우 사용자는 문제나 해결방법에 대한 완전한 이해 없이 시스템을 발주한다. 유지보수 프로젝트의 경우에도 변경될 기능이 충분히 정의되지 않은 상황에서 비용을 산정하는 경우가 많다.

 

두 번째로 프로젝트가 진행됨에 따라 사용자 또는 개발자들이 보다 많은 기능과 변경사항이 제품에 포함될 것을 요구한다는 사실이다.

 

세 번째로 개발이 시작되기 전에 복잡한 시스템의 요구사항을 정확하고 완전하게 기술하는 것이 불가능하다는 점이다. 이러한 문제점은 사용자나 개발자의 능력과는 무관하게 복잡한 시스템 자체의 특성이라고 볼 수 있다. 개발하고자 하는 시스템이 기존에 개발된 시스템과 거의 동일하지 않는 한 요구사항은 부정확하고 불완전하게 기술될 수밖에 없다. 요구사항이 발주기관의 제안요청서(Request For Proposal, RFP)에 기술되고 이를 기초로 개발자가 수행계획서를 제출한다고 할지라도, 사업이 진행됨에 따라 개발자와 발주기관이 제안요청서상의 요구사항의 의미와 비용 변동사항에 대해 상반된 견해를 주장하는 경우가 자주 있다.

 

요구사항과 관련된 그 밖의 문제점들로는 요구사항을 기술하는 방법을 잘 모르는 발주기관의 담당자들에 의해 요구사항이 기술된다는 점이다. 또한, 급격한 기술의 변화로 개발기간이 긴 사업의 경우 시스템 인도 시점이 되면 요구사항들이 기술변화에 뒤쳐진다는 점이다. 이로 인해 사용자는 개발된 시스템에 불만을 갖게 된다. 또, 발주기관의 사용자들이 바뀜으로 인해 요구사항도 변경된다는 점이다.

 

② 유지보수와 관련된 문제점

제품의 전체 수명주기 동안의 소프트웨어 유지보수 비용이 개발비용보다 훨씬 많음에도 불구하고 소프트웨어 유지보수 비용을 크게 고려하지 않는 경향이 있다. 개발자가 유지보수성을 얼마나 고려하느냐에 따라 시스템 개발비용이 달라질 수 있다. 왜냐하면, 개발 기간이나 비용에 대한 제약이 강하다면 개발자는 유지보수성을 무시하는 경향이 있기 때문이다. 개발자는 개발시스템의 인도와 함께 책임이 없어지므로 유지보수에 드는 노력에는 이해 관계가 없어진다. 따라서, 개발자는 요지보수가 쉬운 소프트웨어를 인도하기 보다는 주어진 예산과 기간에 맞춰 사업을 종료하는데 주안점을 두게 된다.

 

③ 소프트웨어 획득 프로세스와 관련된 문제점

이상적인 소프트웨어 원가 산정 프로세스에서는 입력으로 시스템 요구사항이 들어와서 출력으로 원가 추정치가 계산되어야 하지만, 현실적으로 그렇지 못하다. 많은 경우 요구사항이외에 제약조건들이 원가 산정 프로세스에 영향을 준다. 대부분의 공공기관에서 사업이 시작되기 전에 예산을 확보하여야 하고 예산 확보를 위해 개략적이고 모호한 자료로부터 원가 추정치를 산출한다. 그리고, 일단 확보된 예산의 변경은 매우 어려운 실정이다.

개발자는 발주기관에 의해 확보된 예산을 불변의 사실로 받아들이고 주어진 기간과 예산에 맞추어 제품을 인도해야만 한다. 이러한 점 때문에 소프트웨어의 유지보수성을 향상시키도록 개발자를 동기부여할 수가 없게 된다. 개발자의 관점에서 보면 이러한 획득 프로세스는 개발자로 하여금 소프트웨어 원가를 요구사항의 함수형태로 산정할 필요가 없게 만든다.

발주기관이 소프트웨어 획득을 위해 일정 예산을 확보해 둔 상태에서 개발자가 사업을 수주하기 위해서는 확보된 예산보다 적게 입찰에 참여할 수밖에 없다.

 

④ 시스템 규모와 관련된 문제점

대규모 시스템의 개발 비용은 예외 없이 상당히 과소 산정되어 왔다. 대규모 시스템은 매우 복잡하고, 소스코드의 라인 수가 증가할수록 시스템의 복잡성은 지수적으로 커지게 된다. 시스템 규모가 크고 개발기간이 길수록 요구사항을 정확하고 완전하게 명세하는 것이 그만큼 어려워진다. 또한, 개발기간이 길수록 초기 요구사항에 변경이 많이 발생하게 된다.

 

⑤ 소프트웨어 프로세스/프로세스 성숙도와 관련된 문제점

개발과정에서 무슨 일을 하고 어떻게 일을 해야 하는가를 알지 못하면 정확한 원가 추정치를 만들어 낼 수 없다. 비록 정형화된 문서는 아니더라도 개발팀에 의해 수행되어야 할 작업들이 명확히 정의되어 있어야 원가 추정치를 정확하게 계산해 낼 수 있을 것이다.

원가 산정에 영향을 주는 다른 요소는 CASE 도구의 사용이다. CASE 도구가 소프트웨어 프로세스 내에서 효과적으로 사용되면 이에 대한 고려가 원가 산정 과정에 포함되어야 할 것이다. CASE 도구를 도입함에 따른 원가 산정시 문제점으로는 CASE 도구에 대한 교육비용이 과소 산정되는 경향이 있고, 도구의 효과성이 예상보다 저조한 경우가 많으며, 도구의 기능이 예상과 다른 경우가 있다는 점 등이다. 이러한 이유들로 새로운 CASE 도구의 도입은 예상보다 훨씬 많은 개발 비용을 초래하게 된다.

 

⑥ 프로젝트 진행 상태 추적과 관련된 문제점

소프트웨어 비용과 개발 프로세스가 추적되고 진행상태가 측정되지 않는다면 소프트웨어 비용은 관리될 수가 없다. 프로젝트 상태를 감독하는 데는 두 가지 관점이 있을 수 있다.

프로젝트 관리자(project manager)는 프로젝트의 비용과 일일 진행현황을 감독할 필요가 있다. 발주기관에서는 인도될 시스템이 납기를 맞출 수 있도록 제대로 진행되고 있고 요구사항을 만족하는가를 감독할 필요가 있다. 프로젝트 관리자의 관점에서는 프로젝트의 완성도를 객관적으로 측정하는 방법이 절대적으로 부족하다. 대부분의 조직에서 주어진 작업 담당자가 작업이 완료되었다고 선언할 때 작업이 완료된 것으로 간주하지만, 실제로 완료되지 않은 경우가 많다.

발주기관에서도 검토과정을 통해 진행 상태를 점검하지만 관련 사항의 빈번한 변경과 시스템 복잡성 등으로 인해 프로젝트 진행 상태를 정확히 추적하는데는 한계가 있다.

 

⑦ 과거 자료의 부족으로 인한 문제점

새로운 프로젝트의 원가를 정확하게 산정하기 위해서는 과거에 조직에 의해 수행된 사업에 대한 정보가 필요하다. 작은 조직에서는 핵심 인력의 기억에 의존하여 어느 정도 정확한 예측을 할 수 있지만 대규모 조직에서는 방대한 정보의 체계적인 축적 없이는 정확한 원가를 산정하기가 어렵다.

 

⑧ 전문 분야의 지식 부족으로 인한 문제점

조직의 전문 분야에 관한 지식과 정확한 소프트웨어 원가 산정과는 직접적인 상관관계가 있다. 유사한 시스템을 여러 번 개발해 본 조직은 정확한 원가 추정치를 계산하지만, 신규 개발 시스템이 조직의 전문 분야에 관한 지식과 상이할수록, 원가 추정치의 정확성은 떨어진다.

 

⑨ 전체 시스템이 소프트웨어에 미치는 영향으로 인한 문제점

많은 프로젝트가 단순히 소프트웨어 개발 프로젝트가 아니라 소프트웨어를 포함하는 보다 큰 시스템 개발을 목표로 한다. 소프트웨어의 원가를 산정할 시점에 전체 시스템의 구조가 정해지지 않은 경우가 많다. 이러한 경우 소프트웨어 원가 추정치는 상당히 부정확할 수밖에 없다.

 

 

제 4 장 기능점수 기법

 

4.1 기능점수 분석의 목적 및 활용

기능점수 분석은 사용자의 관점에서 소프트웨어 개발 규모를 산정하는 방법으로, 기능점수 분석은 주로 논리적 설계를 기초로 사용자에게 제공되는 소프트웨어의 기능을 정량화하여 소프트웨어의 규모를 산정한다. 기능점수 분석의 목적은 다음과 같다.

∙ 사용자가 요구하고 수용하는 기능을 정량적으로 산정한다.

∙ 구현 기술과 독립적으로 소프트웨어 개발 및 유지 규모를 측정한다.

이러한 목적을 달성하기 위해서 기능점수 계산 과정은 오버헤드가 되지 않도록 간단하여야 하고, 다양한 프로젝트나 조직에 상관없이 일관성을 가져야 한다.

 

기능점수 분석은 다음과 같이 활용될 수 있다.

∙ 구매하고자 하는 응용패키지의 규모를 산정하는 도구

∙ 사용자의 요구에 부합되는 응용패키지의 기능점수를 계산하여 응용패키지의 이점을 측정하는 도구

∙ 품질과 생산성 분석을 지원하는 소프트웨어 제품의 개수 산정을 위한 도구

∙ 소프트웨어 개발과 유지보수를 위한 비용과 자원 소요 산정을 위한 도구

∙ 소프트웨어 비교를 위한 공통 기준

본 장에서는 IFPUG[7]에서 제시한 매뉴얼을 기초로 하여 기능점수의 계산 절차와 세부적인 방법을 알아본다.

 

4.2 기능점수 계산 절차

기능점수 계산을 위한 상위수준의 절차는 다음 그림과 같다.

① 기능점수 계수 유형 결정

기능점수 계수 유형은 프로젝트 또는 응용시스템과 연관되는데 세 가지 계수 유형이 있다.

∙ 개발프로젝트 기능점수 계수

∙ 유지보수 프로젝트 기능점수 계수

∙ 응용패키지 기능점수 계수

 

② 계수 범위와 응용 영역 설정

계수 범위 설정이란 기능점수 계수에 포함될 기능성을 정의하는 것을 말한다. 응용영역 설정이란 측정대상이 되는 소프트웨어와 사용자간의 경계를 정의하는 것을 말한다.

 

③ 보정전 기능점수 계수 결정

보정전 기능점수는 개발프로젝트 또는 응용패키지에 의해 사용자에게 제공되는 기능의 개수를 말한다. 응용패키지의 기능 개수는 기능이 어떻게 제공되는냐 보다는 무슨 기능이 제공되는가라는 관점에서 평가되어야 한다. 이 때, 반드시 사용자가 요구하고 정의한 기능만 포함하여야 한다.

 

보정전 기능점수 계수는 데이터영역과 처리영역이라는 두 가지 유형을 갖는다. 이러한 두 가지 유형을 보다 세분화하면 다음 그림과 같다.

데이터영역 기능(data function)은 내부 및 외부 자료 요구사항을 만족시키기 위해 사용자에게 제공되는 기능들을 말한다. 데이터 영역 기능은 내부로직파일(Internal Logical File, ILF)이거나 외부인터페이스파일(External Logical File, EIF)로 구분된다. 내부로직파일은 응용시스템 영역안에서 유지되고 사용자가 식별가능한 논리적으로 연관된 자료 및 제어정보의 그룹을 말한다. 내부로직파일의 기본적인 용도는 계수 대상이 되는 응용시스템의 하나 또는 그 이상의 기본프로세스에서 유지되는 데이터를 저장하는 것이다. 외부인터페이스파일은 응용시스템에서 참조되지만 다른 응용시스템에서 유지되며 사용자가 식별가능한 논리적으로 연관된 자료 및 제어정보의 그룹을 말한다. 외부인터페이스파일은 기본적인 용도는 계수 대상이 되는 응용시스템내의 하나 또는 그 이상의 기본프로세스에서 참조되는 데이터를 저장하는 것이다. 이는 외부인터페이스파일은 반드시 다른 응용시스템의 내부로직파일이 됨을 의미한다.

 

처리영역 기능(transactional function)은 데이터를 처리하기 위해 사용자에게 제공되는 기능들을 말한다. 처리영역 기능에는 외부입력(external input), 외부출력(external output), 외부조회(external inquiry) 등이 있다. 외부입력은 응용시스템 외부에서 들어오는 데이터 및 제어정보를 처리하는 기본프로세스라 볼 수 있다. 외부입력은 주로 하나 또는 그 이상의 내부로직파일을 유지하거나 시스템의 작동상태를 변경하는 데 사용된다.

 

외부출력은 응용시스템 밖으로 데이터나 제어정보를 보내는 기본프로세스이다. 외부출력은 주로 데이터 및 제어정보의 조회 외에 처리로직을 통해 사용자에게 정보를 제공하는 데 사용된다. 처리로직은 적어도 하나 이상의 수학적 공식 및 계산식을 포함하거나 유도되는 데이터를 생성해야 한다. 또한, 외부출력은 하나 또는 그 이상의 내부로직파일을 유지하거나 시스템의 작동상태를 변경할 수도 있다.

 

외부조회는 응용시스템 외부에 데이터나 제어정보를 보내는 기본프로세스이다. 외부조회는 주로 데이터나 제어정보의 조회를 통해 사용자에게 정보를 제공하는 데 있다. 처리로직은 수학적 공식이나 계산식을 포함하지 않으며, 유도되는 데이터를 생성하지도 않는다. 또한, 처리과정에 내부로직파일이 유지되지 않으며, 시스템 작동상태도 변경되지 않는다.

 

④ 보정 계수 결정

보정계수는 응용시스템 사용자에게 제공되는 전반적인 기능성을 의미하는데, 14개의 시스템 특성으로 이루어져 있다. 각 시스템 특성의 영향 정도는 0에서 5까지의 척도로 평가된다.

 

⑤ 보정된 기능점수 계수 계산

보정된 기능점수 계수는 계산 유형별(개발프로젝트, 유지보수 프로젝트, 응용패키지)로 해당 공식을 사용하여 계산된다.

 

4.3 소프트웨어 수명주기와 규모산정

사용자 요구사항은 프로젝트 초기단계에 급격하게 변화한다. 따라서, 사용자와 개발자간에 소프트웨어에 어떠한 기능들이 포함되어야 하는가에 대한 합의가 반드시 이루어져야 한다. 포함되어야 할 기능들에 관한 의사결정은 조직의 필요, 개발프로젝트에 관련된 위험, 개발프로젝트에 할당될 수 있는 조직의 자원, 조직의 가용한 기술 등에 영향을 받는다.

 

개발프로젝트 초기에는 가능성에 대한 검토가 이루어진다. 가능성에 대한 검토는 가장 상위수준의 시스템 규격을 다루고 보통 매우 간략한 형태를 띤다. 가능성에 대한 검토가 끝난 후에, 사용자는 시간이 지남에 따라 보다 정확한 요구사항을 이끌어내고 어느 시점에 가면, 사용자는 상세 요구사항을 작성하기 위해 소프트웨어 개발자에게 자문을 구하게 된다. 소프트웨어 개발자는 가능성 검토결과를 기초로 하여 개발 및 구현 요구사항을 작성하기 시작하고, 사용자와 개발자는 토론을 걸쳐 보다 개선된 요구사항을 만들어 낸다. 개발 프로세스는 조직마다 다르지만 요구사항 명세 과정을 크게 세 단계로 나누어보면 초기 사용자 요구사항 명세, 초기 기술적 요구사항 명세, 최종 기능 요구사항 명세로 나눌 수 있다.

 

사용자와 개발자간의 의견 교환이 발생하기 전에 초기 사용자 요구사항은 불완전하고, 필수 기능이 누락되기도 한다. 또한, 구현 불가능하거나 사용하기 불편할 수도 있고, 매우 일반적이고, 사용자마다 기능요구사항이 달라지기도 한다. 개발소프트웨어의 영역을 고려하지 않은 요구사항도 있을 수 있고, 기능점수 분석에서 사용되는 용어나 상황에 맞지 않게 표현될 수도 있다.

초기 기술적 요구사항은 가능성 검토결과로부터 만들어지는 개발자의 관점을 기술한 것이다. 소프트웨어 개발자의 업무는 요구사항을 기존에 존재하는 응용들로 조직화하는 것이다. 초기 기술적 요구사항은 기능점수 계수에 포함되지는 않고 구현에 필요한 요소들을 포함할 수도 있다. 또한, 초기 기술적 요구사항은 기술에 의존적이고, 사용자의 기능적 필요성을 잘못 식별할 수 있으며, 사용자에게 익숙하지 않은 용어들을 포함하게 된다. 또한, 기술적 제약을 지나치게 강조하여 기능들이 결정될 수도 있고, 조직의 다른 응용시스템의 기술적 구조에 따라 시스템 영역이 결정될 수 있다.

 

마지막 단계인 최종 기능 요구사항은 사용자와 개발자간의 협의를 거쳐 도출되며, 양자간의 협의는 일관성 있고 완전한 소프트웨어의 기능 요구사항을 이끌어내기 위해 필수적이다. 최종 기능 요구사항은 개발단계를 시작하기 전의 최종적인 요구사항으로 사용자와 개발자가 모두 이해할 수 있는 용어를 사용하여 다른 사용자로부터 도출된 모든 사용자 요구사항을 통합적으로 기술한다. 또한, 기능점수를 정확하게 계산할 수 있도록 충분하고 일관성 있는 요구사항을 담고 있으며, 사용자에 의해 프로세스나 데이터 그룹이 승인되고 개발자에 의해 가능성과 편의성이 승인된 것이다.

 

소프트웨어의 기능점수를 산정하기 전에 소프트웨어의 수명 단계를 확인하고 소프트웨어의 규모를 근사적으로 산정할 것인지 아니면 정확한 규모 산정을 할 것인가를 결정해야 한다. 근사적 규모산정은 알려지지 않는 기능들에 대한 가정을 허용하지만 정확한 규모 산정은 모든 기능들과 복잡도 등을 식별해야 가능하다. 소프트웨어 수명 주기 단계와 규모 산정 가능 여부를 나타나면 다음 표와 같다.

수명주기의 단계

근사적인 규모 산정

가능여부

정확한 규모 산정

가능여부

제안

가능

불가능

요구사항 분석

가능

가능

설계

가능

가능

구축

가능

가능

설치

가능

가능

유지보수

가능

가능

 

4.4 기능점수 계산 형태

기능점수 계수는 3 가지 유형이 있다.

 

① 개발 프로젝트

프로젝트 종료시에 인도/설치된 소프트웨어가 사용자에게 제공하는 기능점수를 산정한다.

 

② 개선 프로젝트

기존 프로그램에 추가/변경/삭제 등 수정된 소프트웨어의 규모를 측정한다.

 

③ 응용프로그램

현재의 응용프로그램이 사용자에게 제공하는 기능점수를 측정하는 것으로서, 개발 프로젝트가 종료된 후부터 이후의 개선 프로젝트에 의해 변경될 때마다 기능점수가 갱신된다.

주의해야 할 점은 초기 단계의 기능점수 계수는 최종 인도될 소프트웨어의 기능점수의 추정치라는 사실이다. 소프트웨어의 범위가 명확해지고 기능들이 개발됨에 따라 새로운 기능들이 추가된다.

 

4.5 계수 범위와 영역 설정

기능점수 계수 범위는 기능점수 계수에 포함될 기능들을 정의한다. 예를 들어, 유지보수 프로젝트의 경우 추가되거나 수정, 삭제되는 모든 기능들이 기능점수 계수에 포함된다. 개발프로젝트는 프로젝트 활동에 의해 영향을 받는 모든 기능들이 기능점수 계수에 포함된다.

응용시스템 영역은 측정대상이 되는 소프트웨어와 사용자간의 경계를 말한다. 응용시스템 영역은 내부 소프트웨어와 외부 사용자간의 개념적 인터페이스로서, 응용시스템에서 유지되는 논리적 데이터를 포괄해야 하고, 응용시스템이 참조하는 외부 논리적 데이터의 식별도 지원할 수 있어야 한다. 응용시스템 영역은 응용시스템에 대한 사용자의 외적 사업관점에 종속적이지만, 구현이나 기술적 고려사항과는 무관하게 결정된다. 즉, 응용시스템 영역 결정은 사용자의 관점에서 사용자가 이해하고 기술할 수 있는 사항에 초점을 맞추어야 한다. 또한, 관련 시스템간의 경계는 기술적 고려사항이 아니라 사용자에 의해 보여지는 기능영역에 기초하여 결정해야 한다. 그리고, 이미 결정된 응용시스템 영역은 계수범위에 영향을 받지 않는다.

 

4.6 데이터 영역 기능점수 산정

데이터 영역 기능은 내외부 자료 요구사항을 충족시키기 위해 사용자에게 제공되는 기능을 말한다. 데이터 영역 기능은 크게 내부로직파일(Internal Logical File, ILF)과 외부인터페이스파일(External Interface File, EIF)로 구분된다. 여기서 파일은 전통적인 자료처리에서 사용되는 파일의 의미가 아니라 논리적으로 관련 있는 데이터 그룹을 말한다. 내부논리파일과 외부인터페이스 파일의 정의와 규모 산정 절차 및 규칙들을 알아본다.

먼저 사용되는 용어들에 대한 정의는 다음과 같다.

 

∙제어정보(control information) : 산정 대상되는 소프트웨어의 기본프로세스에 영향을 주는 데이터. 제어정보는 무엇이 언제 어떻게 처리되는가를 명시한다.

∙사용자 식별가능(user identifiable) : 사용자와 개발자 모두에게 합의되고 이해 가능한 데이터 그룹이나 프로세스에 대한 명확한 요구사항이어야 함을 말한다.

∙유지(maintained) : 유지된다는 것은 기본프로세스를 통해 데이터를 수정 가능함을 말한다.

∙기본프로세스(elementary process) : 사용자에게 의미 있는 가장 작은 단위의 활동.

내부로직파일은 응용시스템 영역 안에서 유지되고 사용자가 식별 가능한 논리적으로 연관된 자료 및 제어정보의 그룹을 말한다. 내부로직파일의 기본적인 용도는 계수 대상이 되는 응용시스템의 하나 또는 그 이상의 기본프로세스에서 유지되는 데이터를 저장하는 것이다. 외부인터페이스파일은 응용시스템에서 참조되지만 다른 응용시스템에서 유지되며 사용자가 식별 가능한 논리적으로 연관된 자료 및 제어정보의 그룹을 말한다. 외부인터페이스파일은 기본적인 용도는 계수 대상이 되는 응용시스템내의 하나 또는 그 이상의 기본프로세스에서 참조되는 데이터를 저장하는 것이다. 이는 외부인터페이스파일은 반드시 다른 응용시스템의 내부로직파일이 됨을 의미한다.

 

데이터 영역의 기능점수를 산정하기 위해서는 먼저 내부로직파일을 식별하고, 다음에 외부로직파일을 식별해야 한다. 마지막으로, 내부/외부로직파일의 복잡도와 각각이 차지하는 보정전 기능점수를 산정한다.

 

① 내부로직파일 식별 규칙

내부로직파일을 식별하기 위해서 다음 두 가지 조건을 모두 만족하는 데이터나 제어정보의 그룹을 조사한다.

∙ 논리적이고 사용자가 식별 가능해야 한다.

∙ 산정 대상이 되는 응용시스템내의 기본프로세스에 의해 유지되어야 한다.

 

② 외부로직파일 식별 규칙

외부로직파일을 식별하기 위해서 다음 네 가지 조건을 모두 만족하는 데이터나 제어정보의 그룹을 조사해야 한다.

∙ 논리적이고 사용자가 식별 가능해야 한다.

∙ 산정 대상이 되는 응용시스템의 외부에 있으며 응용시스템에 의해 참조되어야 한다.

∙ 산정 대상이 되는 응용시스템에 의해 유지되지 않아야 한다.

∙ 다른 응용시스템의 내부로직파일로 유지되어야 한다.

 

③ 복잡도와 기능점수 산정 규칙

내∙외부로직파일의 개수와 기능의 복잡도에 의해 보정전 기능점수가 계산된다. 각각의 내∙외부로직파일의 기능 복잡도는 데이터 요소 유형과 레코드 요소 유형에 의해 결정된다. 데이터 요소 유형과 레코드 요소 유형의 정의는 다음과 같다.

 

∙ 데이터 요소 유형(Data Element Type, DET)

데이터 요소 유형은 사용자가 인식할 수 있는 반복이 없는 유일한 필드(field)를 말한다. 기본프로세스 수행을 통해 내∙외부로직파일에 의해 참조∙유지되고 사용자가 인식할 수 있고 반복이 없는 유일한 필드를 하나의 DET로 산정한다. 예를 들어, 몇 개의 필드로 구성되는 하나의 계정번호는 하나의 DET로 간주한다. 동일한 내∙외부논리파일이 두 개의 응용시스템에 의해 참조∙유지되지만 서로 다른 DET를 참조∙유지하는 경우에는 각각의 응용시스템에 의해 사용되는 DET만 개수에 포함해야 한다. 또한, 다른 내∙외부로직파일과 관계를 설정하기 위해 사용자에 의해 요구되는 데이터 그룹도 하나의 DET로 간주한다. 예를 들어, 종업원 정보 안에 포함된 종업원 담담업무명은 조직의 업무와 종업원과의 관계를 짓기 위해 필요한 외래키(foreign key)이므로 하나의 DET로 계산된다.

 

∙ 레코드 요소 유형(Record Element Type, RET)

레코드 요소 유형은 사용자가 인식 가능한 내∙외부로직파일 내의 데이터 요소들의 그룹을 말한다. 데이터 요소들의 그룹에는 크게 선택 그룹(optional subgroup)과 필수 그룹(mandatory group)이 있다. 선택 그룹은 기본프로세스에서 선택적으로 생성할 수 있는 데이터 그룹이고, 필수 그룹은 반드시 하나 이상 생성해야 하는 데이터 그룹이다. 예를 들어, 종업원을 새로 등록하는 경우 급여 지급 방식이 시간제인지 월급제인지는 반드시 입력해야 할 필수 그룹인 반면에 종업원의 부양가족은 입력하지 않아도 되는 선택 그룹이다. RET의 개수를 산정할 때는 내외부로직파일의 선택/필수 그룹을 하나의 RET로 간주하거나 또는 데이터 그룹이 없는 경우에는 내외부로직파일을 하나의 RET로 간주한다.

 

∙ 복잡도와 보정전 기능점수 계산

내외부로직파일의 복잡도와 보정전 기능점수를 산정하는 절차는 다음의 네 단계를 거친다.

 

단계 1. RET와 DET를 식별하고 그 개수를 계산한다.

단계 2. 복잡도 행렬을 사용하여 각각의 ILF/EIF의 기능복잡도를 매긴다.

DET 개수

1~19

20~50

51개 이상

RET

개수

1

Low

Low

Average

2~5

Low

Average

High

6개 이상

Average

High

High

 

단계 3. 변환표를 사용하여 내∙외부로직파일의 보정전 기능점수를 구한다.

기능 복잡도 등급

보정전 기능점수

Low

7

Average

10

High

15

기능 복잡도 등급

보정전 기능점수

Low

5

Average

7

High

10

 

단계 4. 내∙외부로직파일의 기능점수 합계를 구한다.

 

4.7 처리영역 기능점수 산정

처리영역 기능은 데이터 처리를 위해 사용자에게 제공되는 기능들을 말한다. 처리영역 기능은 외부입력(External Input, EI), 외부출력(External Output, EO), 외부조회(External Inquiry, EQ)로 나뉜다.

 

① 외부입력(EI)

외부입력은 응용시스템 외부에서 들어오는 데이터 및 제어정보를 처리하는 기본프로세스로서, 주로 하나 또는 그 이상의 내부로직파일을 유지하거나 시스템의 작동상태를 변경하는 데 사용된다.

 

② 외부출력(EO)

외부출력은 응용시스템 밖으로 데이터나 제어정보를 보내는 기본프로세스로서, 주로 데이터 및 제어정보의 조회 외에 처리로직을 통해 사용자에게 정보를 제공하는 데 사용된다. 처리로직은 적어도 하나 이상의 수학적 공식 및 계산식을 포함하거나 유도되는 데이터를 생성해야 한다. 또한, 외부출력은 하나 또는 그 이상의 내부로직파일을 유지하거나 시스템의 작동상태를 변경할 수도 있다.

 

③ 외부조회(EQ)

외부조회는 응용시스템 외부에 데이터나 제어정보를 보내는 기본프로세스로서, 외부조회는 주로 데이터나 제어정보의 조회를 통해 사용자에게 정보를 제공하는 데 있다. 처리로직은 수학적 공식이나 계산식을 포함하지 않으며, 유도되는 데이터를 생성하지도 않는다. 또한, 처리과정에 내부로직파일이 유지되지 않으며, 시스템 작동상태도 변경되지 않는다.

이상에서 알 수 있듯이 EI, EO, EQ간의 중요한 차이점은 각각이 사용되는 목적에 있다. 다음 표는 EI, EO, EQ의 사용목적을 비교한 것이다.

기능

처리영역 기능 유형

EI

EO

EQ

시스템 동작을 변경한다

PI

F

N/A

하나 또는 그 이상의 ILF를 유지한다

PI

F

N/A

사용자에게 정보를 제공한다

F

PI

PI

 

 

PI: 주목적임, F: 주목적은 아니지만 존재할 수 있는 기능임, N/A: 허용되지 않음.

또한, EI, EO, EQ에 의해 수행되는 처리로직 형태도 다른데, 이를 요약하면 다음 표와 같다.

처리 로직 형태

처리 영역의 기능 유형

EI

EO

EQ

1. 자료의 유효성을 확인한다.

c

c

c

2. 수학적 공식이나 계산을 수행한다.

c

m*

n

3. 동등한 값으로 변환하는 과정을 수행한다.

c

c

c

4. 특정 조건에 맞는 데이터를 추출한다.

c

c

c

5. 프로세스 수행을 위해 조건을 분석한다.

c

c

c

6. 하나이상의 ILF가 갱신된다.

m*

m*

n

7. 하나이상의 ILF 또는 EIF가 참조된다.

c

c

m

8. 데이터와 제어정보가 조회된다.

c

c

m

9. 기존 자료로부터 계산된 자료가 생성된다.

c

m*

n

10. 시스템의 작동방식이 변경된다.

m*

m*

n

11. 영역 밖으로 자료를 준비하여 출력한다.

c

m

m

12. 영역 안으로 들어오는 데이터나 제어정보를 받아들일 수 있다.

m

c

c

13. 데이터들을 재정렬하거나 재배열한다.

c

c

c

m: 해당 처리로직을 필수적으로 수행한다.

m*: 처리영역의 기능유형이 m* 표시된 처리로직 중 하나 이상은 반드시 수행한다.

c: 해당 처리로직을 선택적으로 수행한다.

n: 해당 처리로직을 수행하지 않는다.

 

처리 영역의 기능점수를 산정하는 개략적인 절차는 다음과 같다.

단계 1. 기본프로세스를 식별한다.

단계 2. 식별된 기본프로세스들의 기본용도를 결정하여 EI, EO, EQ로 분류한다.

단계 3. EI, EO, EQ 식별 기준에 맞는지 확인한다.

단계 4. 처리영역 복잡도(transaction complexity)를 결정한다.

단계 5. 처리영역의 보정전 기능점수를 결정한다.

 

각 단계별로 세부절차를 알아본다.

 

① 기본프로세스 식별 규칙

기본프로세스를 식별하기 위해 다음 두 가지 사항을 만족하는 프로세스를 조사한다.

∙ 사용자에게 의미 있는 가장 작은 단위의 활동이다.

∙ 독립적이고 시스템의 상태를 일관되게 유지 또는 변경한다.

 

② 처리영역 기능 유형 결정 규칙

ILF를 유지하거나 시스템 작동을 변경하는 것을 기본 목적으로 하는 기본프로세스가 다음 다섯 가지 규칙을 모두 만족하는가를 검사하여 만족하는 경우 외부입력(EI)으로 분류한다.

 

∙ 시스템 영역 밖으로부터 데이터나 제어정보가 수신된다.

∙ 시스템 영역 밖에서 들어오는 자료가 시스템 작동을 변경하는 제어정보가 아니라면 적어도 하나 이상의 ILF가 유지된다.

∙ 처리로직이 다른 EI에 의해 수행되는 처리로직과 다르다.

∙ 식별된 데이터 요소들이 다른 EI에서 식별된 데이터 요소들과 다르다.

∙ 참조되는 ILF/EIF가 다른 EI에서 참조되는 ILF/EIF와 다르다.

사용자에게 정보를 출력하는 것을 기본목적으로 하는 기본프로세스가 다음 네 가지 규칙을 모두 만족하면 외부출력(EO) 또는 외부조회(EQ)로 분류한다.

 

∙ 시스템 영역 밖으로 데이터나 제어정보를 보낸다.

∙ 처리로직이 다른 외부출력이나 외부조회의 처리로직과 유일하게 구분된다.

∙ 식별된 데이터 요소들이 다른 외부출력이나 외부조회의 데이터 요소들과 다르다.

∙ 참조되는 ILF/EIF가 다른 외부출력이나 외부조회에 의해 참조되는 ILF/EIF와 다르다.

외부출력 또는 외부조회로 분류된 기본프로세스가 다음 네 가지 조건 중의 한 개라도 만족하면 외부출력으로 분류한다.

 

∙ 기본프로세스의 처리로직에 적어도 하나 이상의 수학적 공식이나 계산이 포함된다.

∙ 기본프로세스의 처리로직이 유도된 자료를 생성한다.

∙ 기본프로세스의 처리로직이 적어도 하나 이상의 ILF를 유지한다.

∙ 기본프로세스의 처리로직이 시스템의 작동방식을 변경한다.

 

외부출력 또는 외부조회로 분류된 기본프로세스가 다음 다섯 가지 조건을 모두 만족하면 외부조회로 분류한다.

∙ 기본프로세스의 처리로직이 ILF 또는 EIF로부터 데이터나 제어정보를 조회한다.

∙ 기본프로세스의 처리로직이 수학적 공식이나 계산을 포함하지 않는다.

∙ 기본프로세스의 처리로직이 유도된 자료를 생성하지 않는다.

∙ 기본프로세스의 처리로직이 ILF를 유지하지 않는다.

∙ 기본프로세스의 처리로직이 시스템 작동방식을 변경하지 않는다.

 

③ 처리영역 복잡도 결정과 보정전 기능점수 계산

처리영역의 기능점수는 EI, EO, EQ의 개수와 각각의 처리영역 기능유형의 복잡도에 의해 결정된다. 처리영역 기능유형의 복잡도는 참조파일유형(File Type Referenced, FTR)과 데이터 요소 유형(Data Element Type, DET)의 개수에 의해 결정된다. 여기서, 참조파일유형(FTR)은 처리영역 기능이 참조∙유지하는 내부로직파일 또는 처리영역 기능이 참조하는 외부로직파일을 말한다. 데이터 요소 유형은 앞 절의 정의처럼 사용자가 인식가능한 반복이 없는 고유한 필드를 말한다.

 

외부입력(EI)의 FTR의 개수를 결정하는 규칙은 다음과 같다.

∙ 유지되는 하나의 ILF를 하나의 FTR로 간주한다.

∙ 외부입력의 처리로직에 의해 참조되는 각각의 ILF/EIF를 하나의 FTR로 간주한다.

∙ 유지되거나 참조되는 각각의 ILF를 하나의 FTR로 간주한다.

외부입력(EI)의 DET를 결정하는 규칙은 다음과 같다.

∙ 외부입력을 달성하기 위해 시스템 영역에 들어오거나 나가고 사용자가 인식가능하며 반복이 없는 각각의 필드를 하나의 DET로 간주한다.

∙ 필드가 시스템 영역의 경계를 넘나들지 않으면 시스템에 의해 조회∙유도되고 ILF내에 저장된다 할지라도 DET로 간주하지 않는다.

∙ 시스템 영역 밖으로 에러발생, 수행완료 또는 수행계속 여부를 묻는 시스템 메시지를 보내는 기능은 하나의 DET로 간주한다.

∙ 논리적으로 동일한 프로세스를 호출하는 여러 가지 방법이 존재하더라도 해당 프로세스의 호출하는 것은 하나의 DET로 간주한다.

 

외부출력과 외부조회의 복잡도를 결정하기 위해 FTR과 DET의 개수를 산정하는 규칙을 알아본다. 먼저, 외부출력과 외부조회의 FTR를 산정하기 위해 공통적으로 적용되는 규칙은 다음과 같다.

∙ 기본프로세스의 처리과정에서 참조되는 각각의 ILF/EIF를 하나의 FTR로 간주한다.

외부출력의 FTR를 산정하는 데 사용되는 부가적인 규칙은 다음과 같다.

∙ 기본프로세스의 처리과정에서 유지되는 각각의 ILF는 하나의 FTR로 간주한다.

∙ 기본프로세스의 처리과정에서 유지되고 참조되는 각각의 ILF를 하나의 FTR로 간주한다.

 

외부출력과 외부조회의 DET를 결정하기 위해 공통적으로 사용되는 규칙은 다음 여덟 가지이다.

∙ 사용자가 인식가능하고 반복되지 않는 필드로서 시스템 영역 안으로 들어오며 기본프로세스가 언제, 어떻게, 무슨 데이터를 조회∙생성할 것인지를 명시하는데 필요한 필드를 하나의 DET로 간주한다.

∙ 사용자가 인식가능하고 반복되지 않는 필드로서 시스템 영역 밖으로 나가는 필드를 하나의 DET로 간주한다.

∙ 시스템 영역 밖으로 나가기도 하고 들어오기도 하는 하나의 DET는 한번만 개수에 포함시킨다.

∙ 시스템 영역 밖으로 에러발생, 수행완료 또는 수행계속 여부를 묻는 시스템 메시지를 보내는 기능은 하나의 DET로 간주한다.

∙ 논리적으로 동일한 프로세스를 호출하는 여러 가지 방법이 존재하더라도 해당 프로세스의 호출하는 것은 하나의 DET로 간주한다.

∙ 필드가 시스템 영역의 경계를 넘나들지 않으면 시스템에 의해 조회∙유도되고 ILF내에 저장된다 할지라도 DET로 간주하지 않는다.

∙ 문자열 상수는 DET로 간주하지 않는다. 예를 들어, 보고서 제목이나 필드명 등은 DET로 간주하지 않는다.

∙ 페이지 번호나 시스템이 생성한 시간/날짜, 위치 정보 등은 DET에 포함시키지 않는다.

외부입력과 외부출력, 외부조회의 FTR과 DET의 개수가 결정되면 각각의 복잡도는 다음 복잡도 행렬에 의해 결정된다.

DET 개수

1~4

5~15

16이상

FTR개수

0~1

Low

Low

Average

2

Low

Average

High

3이상

Average

High

High

DET 개수

1~5

6~19

20이상

FTR개수

0~1

Low

Low

Average

2~3

Low

Average

High

4이상

Average

High

High

 

처리영역 기능유형별 복잡도가 결정되면 각각의 보정전 기능점수는 다음 표에 의해 산출한다.

복잡도

보정전 기능점수

Low

3

Average

4

High

6

복잡도

보정전 기능점수

Low

4

Average

5

High

7

 

4.8 보정요소 결정

보정요소는 계수 대상 시스템의 다음과 같이 14 개의 전반적인 시스템 특성(General System Characteristic, GSC)에 기반하고 있다([7]).

∙ 데이터 통신(Data Communications)

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

∙ 성능(Performance)

∙ 사용환경(Heavily Used Configuration)

∙ 처리율(Transaction Rate)

∙ 온라인 데이터 입력(Online Data Entry)

∙ 최종사용자 편리성(End-Used Efficiency)

∙ 온라인 갱신(Online Update)

∙ 처리복잡성(Complex Processing)

∙ 재사용성(Reusability)

∙ 설치용이성(Installation Ease)

∙ 운영용이성(Operational Ease)

∙ 복수 사이트(Multiple Sites)

∙ 변경 용이성(Facilitate Change)

각각의 시스템 특성은 영향도(Degree of Influence, DI)는 0에서 5까지 척도로 평가된다.

척 도

의 미

0

존재하지 않거나 전혀 영향이 없음.

1

영향이 있으나 주요하지 않음.

2

어느 정도 영향이 있음.

3

평균 정도로 영향이 있음.

4

중요한 영향이 있음.

5

매우 강한 영향이 있음.

 

① 데이터 통신(Data Communications)

데이터 통신은 응용시스템이 프로세서와 직접적으로 통신하는 정도를 말한다. 응용시스템에서 사용되는 데이터와 제어정보는 통신설비를 통해 송수신된다. 중앙처리장치에 연결된 단말기는 통신설비를 사용하는 것으로 볼 수 있다. 프로토콜(protocol)은 두 개의 시스템 또는 장치간에 정보의 교환이나 전송을 가능케 하기 위해 합의된 것들의 집합이다. 모든 데이터 통신은 어떤 형태의 프로토콜을 필요로 한다.

데이터 통신의 영향 정도는 다음 표와 같이 평가된다.

척 도

의 미

0

순수한 배치처리이거나 독립적인 PC환경에서 수행됨.

1

배치 처리이지만 원격 데이터 입력 또는 원격 출력이 있음.

2

배치 처리이지만 원격 데이터 입력과 출력이 있음.

3

온라인 자료 수집과 배치처리나 조회시스템에 대한 TP 프런트엔드을 포함한다.

4

프런트엔드 이상이지만 한가지 형태의 TP 통신 프로토콜만 지원한다.

5

프런트엔드 이상이고, 한가지 이상의 TP 통신 프로토콜을 지원한다.

 

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

분산 데이터 처리는 시스템 컴포넌트간의 데이터 전송정도를 나타낸다. 분산 데이터 처리는 시스템 영역 내에서의 시스템 특성이다.

척 도

의 미

0

컴포넌트간의 데이터 전송을 지원하지 않는다.

1

시스템의 다른 컴포넌트에서 사용자가 처리할 수 있도록 데이터를 준비한다.

2

전송할 수 있도록 데이터가 준비되어 전송되고 다른 컴포넌트에서 처리가 이루어진다.

3

분산 처리와 데이터 전송이 온라인으로 한방향으로만 이루어진다.

4

분산 처리와 데이터 전송이 양방향으로 모두 이루어진다.

5

처리 기능이 가장 적절한 컴포넌트에서 동적으로 수행된다.

 

③ 성능(Performance)

수행도는 반응시간(response time)이나 처리량(throughput performance)이 시스템 개발에 미치는 영향정도를 나타낸다.

척 도

의 미

0

성능에 대한 특별한 요구사항이 명시되어 있지 않음.

1

성능이나 설계 요구사항이 명시되고 검토되었으나 특별한 조치가 필요하지 않음.

2

피크(peak) 시간동안의 반응시간이나 처리양이 중요함. CPU 이용을 위한 특별한 설계가 요구되지 않음. 처리 시한이 다음 영업일까지임.

3

영업시간 내내 반응시간이나 처리양이 중요함. CPU 이용을 위한 특별한 설계가 요구되지 않음. 처리시한에 제약이 있음.

4

척도 3에 덧붙여, 성능에 대한 사용자 요구사항이 엄격하여 설계단계에 성능 분석이 요구됨.

5

척도 4에 덧붙여, 성능 요구사항을 충족하기 위해 설계/개발/구현 단계에서 성능분석 도구가 사용됨.

 

④ 사용환경(Heavily Used Configuration)

사용환경은 컴퓨터 자원 제약이 시스템 개발에 미치는 영향도를 나타낸다. 개발할 응용시스템이 부하가 많은 기존 장비에서 수행된다면 설계 단계에서 특별한 고려가 필요하게 된다.

척 도

의 미

0

명시적 또는 암시적 운영제약이 없음.

1

운영제약이 있으나 일반적인 경우보다 덜 제약적이고 제약을 만족하기 위해 특별한 노력이 필요 없음.

2

보안이나 타이밍에 고려가 포함되어 있음.

3

시스템의 특정 부분을 특정한 프로세서에서 수행해야 하는 요구사항이 포함되어 있음.

4

명시된 운영제약에 의해 중앙처리기나 전용처리기상의 응용시스템에 대한 특별한 제약이 요구된다.

5

척도 4에 덧붙여, 시스템의 분산 컴포넌트상의 어플리케이션에 특별한 제약이 존재함.

 

⑤ 처리율(Transaction Rate)

처리율은 처리 속도가 응용시스템 개발에 미치는 영향도를 나타낸다. 처리율이 높아야 한다면 설계, 개발, 설치, 지원 단계에 영향을 미치게 된다.

척 도

의 미

0

피크처리기간이 예견되지 않음.

1

피크처리기간(월별, 분기별, 년별)이 예상됨.

2

주간 피크처리기간이 예상됨.

3

일간 피크처리기간이 예상됨.

4

요구사항이나 SLA에 명시된 처리율이 높아 설계단계에서 성능분석 작업이 요구됨.

5

척도 4에 덧붙여, 설계, 개발, 설치단계에서 성능분석 도구의 사용이 요구됨.

 

⑥ 온라인 데이터 입력(online data entry)

온라인 데이터 입력은 대화형 처리에 의해 데이터가 입력되는 정도를 의미한다.

척 도

의 미

0

모든 트랜잭션이 배치방식으로 처리됨.

1

트랜잭션의 1%~7%가 대화형 입력 방식이다.

2

트랜잭션의 8%~15%가 대화형 입력 방식이다.

3

트랜잭션의 16%~23%가 대화형 입력 방식이다.

4

트랜잭션의 24%~30%가 대화형 입력 방식이다.

5

트랜잭션의 30%이상이 대화형 입력 방식이다.

 

⑦ 최종사용자 편리성(End-Used Efficiency)

최종사용자 편리성은 시스템의 사용편리성에 대한 고려 정도를 나타낸다. 최종사용자 편리성을 위해 설계단계에서

∙ 탐색 기능(기능키, 동적으로 생성되는 메뉴 등)

∙ 메뉴

∙ 온라인 도움말

∙ 커서 자동이동 기능

∙ 스크롤 기능

∙ 온라인 트랜잭션을 통한 원격 출력

∙ 미리 할당한 기능키(function key)

∙ 온라인 트랜잭션에서 수행되는 배치작업

∙ 커서를 이용한 스크린 데이터의 선택

∙ 역상, 하이라이트, 밑줄 등 기타 표시 기능

∙ 온라인 트랜잭션의 하드카피 문서화 기능

∙ 마우스 인터페이스

∙ 팝업 윈도우

∙ 업무기능을 수행할 수 있으면서 최소한의 화면만 사용

∙ 두 가지 언어의 지원

∙ 두 가지 이상의 언어 지원

등을 고려한다.

척 도

의 미

0

위에 고려사항을 하나도 포함하지 않음.

1

1~3개를 고려함.

2

4~5개를 고려함

3

6개 이상을 고려하지만, 사용자 편리성에 대한 특별한 요구사항이 없음.

4

6개 이상을 고려하고, 사용자 편리성에 대한 요구사항이 엄격해 인간공학적 고려가 설계 단계에서 요구됨.

5

6개 이상을 고려하고, 사용자 편리성에 대한 요구사항이 엄격해 요구사항을 만족시키기 위해 특별한 도구나 프로세스가 요구됨.

 

⑧ 온라인 갱신(Online Update)

온라인 갱신은 내부로직파일이 온라인으로 갱신되는 정도를 나타낸다.

척 도

의 미

0

없음.

1

1~3개의 제어파일(control file)의 온라인 갱신이 있음. 갱신량은 작고, 복구(recovery)는 쉬움.

2

4이상의 제어파일의 온라인 갱신이 있음. 갱신량은 작고, 복구(recovery)는 쉬움.

3

중요한 내부로직파일의 온라인 갱신이 있음.

4

척도 3에 덧붙여, 데이터 손실 방지 기능이 필수적이고 설계되고 구현되어야 한다.

5

척도 4에 덧붙여, 대용량으로 인해 복구 프로세스에 비용이 발생함. 운영자 간섭을 최소로 하는 자동복구 과정이 요구됨.

 

⑨ 처리복잡성(Complex Processing)

처리복잡성은 처리 로직이 시스템 개발에 미치는 영향도를 나타낸다. 복잡한 처리 로직 들로는 다음 같은 형태가 있다.

∙ 민감한 제어(예를 들어, 감사 프로세싱)나 특별한 보안 처리

∙ 많은 로직 처리

∙ 많은 수학적 처리

∙ 많은 예외 처리(exception processing)

∙ 여러 가지 형태의 입출력을 처리할 수 있도록 복잡한 처리기능(예를 들어, 멀티미디어, 장치 독립성 등)

척 도

의 미

0

위의 처리유형이 존재하지 않음.

1

위의 처리유형 중 1개를 포함되어 있음.

2

위의 처리유형 중 2개를 포함되어 있음.

3

위의 처리유형 중 3개를 포함되어 있음.

4

위의 처리유형 중 4개를 포함되어 있음.

5

위의 처리유형 모두가 포함되어 있음.

 

⑩ 재사용성(Reusability)

재사용성은 프로그램이나 프로그램 소스가 다른 응용시스템에 사용될 수 있도록 설계/개발/지원되어야 하는 정도를 말한다.

척 도

의 미

0

재사용되지 않음.

1

재사용되는 코드가 존재함.

2

프로그램의 10%이하가 재사용성을 고려함.

3

프로그램의 10%이상이 재사용성을 고려함.

4

개발시스템이 쉽게 재사용되도록 패키지/문서화되고 사용자에 의해 소스코드 수준에서 커스터마이징될 수 있음.

5

개발시스템이 쉽게 재사용되도록 패키지/문서화되고 사용자에 의해 사용자 파라미터 변경을 통해 커스터마이징될 수 있음.

 

⑪ 설치용이성(installation ease)

설치용이성은 기존 환경으로부터 변환이 개발시스템에 미치는 영향도를 나타낸다.

척 도

의 미

0

사용자가 특별한 고려사항을 명시하지 않았으며, 설치를 위해 특별한 초기설정도 필요하지 않음.

1

사용자가 특별한 고려사항을 명시하지 않았으나 설치를 위해 특별한 초기설정이 필요함.

2

변환과 설치 요구사항이 명시되어 있고, 변환/설치 지침이 제공되고 시험되어야 함. 변환의 파급효과는 중대하지 않음.

3

변환과 설치 요구사항이 명시되어 있고, 변환/설치 지침이 제공되고 시험되어야 함. 변환의 파급효과가 중대함.

4

척도 2에 덧붙여, 자동변환 및 설치 도구가 제공되고 시험되어야 함.

5

척도 3에 덧붙여, 자동변환 및 설치 도구가 제공되고 시험되어야 함.

 

⑫ 운영용이성(operational ease)

운영용이성은 시스템 시작, 백업, 복구 작업 등에서 고려할 정도를 나타낸다. 운영용이성은 시스템의 특성으로, 수작업을 최소화할 수 있어야 한다.

척 도

의 미

0

정상적인 백업절차 외에 특별한 운영 고려사항이 없음.

1~4

다음 사항 중에 해당되는 사항의 개수가 척도가 됨.

∙ 효율적인 시스템 시작, 백업, 복구 절차가 제공되어야 하나, 운영자 개입이 필요함.

∙ 효율적인 시스템 시작, 백업, 복구 절차가 제공되어야 하고, 운영자 개입이 없어야 함. (두 개 사항으로 간주)

∙ 자기테이프를 걸어 주는 작업을 최소화해야 한다.

∙ 문서 작업을 최소화해야 한다.

5

시스템이 운영자 개입 없이 자동적으로 운영될 수 있어야 한다. 즉, 운영자가 시작/종료하는 것 외에 나머지 과정을 자동화되어야 한다.

 

⑬ 복수 사이트(Multiple Sites)

복수 사이트란 시스템이 여러 개의 장소나 사용자 기관을 위해 개발되는 정도를 나타낸다.

척 도

의 미

0

두 개이상의 사용자/설치 사이트를 고려할 필요가 없음.

1

설계단계에 여러 사이트를 고려하였고, 동일한 H/W, S/W 환경에서 작동하도록 설계됨.

2

설계단계에 여러 사이트를 고려하였고, 유사한 H/W, S/W 환경하에서만 작동하도록 설계됨.

3

설계단계에 여러 사이트를 고려하였고, 다른 H/W, S/W 환경하에서 작동하도록 설계됨.

4

척도 1 또는 2에 덧붙여, 문서화와 지원계획이 제공되고 시험되어야 한다.

5

척도 3에 덧붙여, 문서화와 지원계획이 제공되고 시험되어야 한다.

 

⑭ 변경 용이성(facilitate change)

변경 용이성은 응용시스템이 처리로직이나 자료구조의 간단한 변경으로 개발될 수 있는 정도를 나타낸다.

다음 특성 중에서 해당되는 특성의 개수가 척도가 된다.

∙ 간단한 요구를 처리할 수 있는 유연한 조회 및 보고 도구가 지원된다. (하나로 센다)

∙ 평균정도의 복잡도를 갖는 요구를 처리할 수 있는 유연한 조회 및 보고 도구가 지원된다. (두 개로 센다)

∙ 복잡한 요구를 처리할 수 있는 유연한 조회 및 보고 도구가 지원된다. (세 개로 센다)

∙ 업무 제어 데이터가 온라인 대화형 프로세스를 통해 유지되는 테이블에 저장되지만, 변경은 다음 영업일에 가서야 영향을 미친다.

∙ 업무 제어 데이터가 온라인 대화형 프로세스를 통해 유지되는 테이블에 저장되지만, 변경은 즉시 영향을 미친다. (두 개로 센다)

 

4.9 보정된 기능점수 계수 산정

보정된 기능점수는 기능점수 계수 유형별로 다른 공식을 통해 계산된다.

 

① 개발프로젝트 기능점수 계산

개발프로젝트의 기능점수는 응용기능(application functionality), 전환기능(conversion functionality), 보정요소에 의해 계산된다. 응용기능은 시스템 설치 이후에 사용자의 업무지속을 위해 사용되는 기능들로 구성되고, 전환기능은 기존 데이터의 전환 등을 위해 소프트웨어 설치단계에 사용되는 기능들로 구성된다. 개발프로젝트의 기능점수는 다음 식에 의해 계산된다.

DFP = (UFP + CFP) * VAF

DFP : 개발프로젝트 기능점수 계수

UFP : 설치 후에 사용가능한 기능들의 보정전 기능점수

CFP : 전환 기능들의 보정전 기능점수

 

② 유지보수프로젝트 기능점수 계산

유지보수프로젝트의 기능점수는 응용기능(application functionality), 전환기능(conversion functionality), 보정요소에 의해 계산된다. 응용기능은 새로 추가된 기능, 기존에 있는 기능 중에서 수정되는 기능, 삭제되는 기능 등으로 구성된다. 전환기능은 전환을 위해 구현된 기능들을 말한다. 유지보수프로젝트의 기능점수는 다음 식에 의해 계산된다.

EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB)

EFP : 유지보수프로젝트의 기능점수 계수

ADD : 유지보수프로젝트에 의해 추가되었거나 추가될 기능들의 보정전 기능점수

CHGA : 유지보수프로젝트에 의헤 수정되었거나 수정될 기능들의 보정전 기능점수

CFP : 전환을 위해 추가된 기능들의 보정전 기능점수

VAFA : 유지보수프로젝트가 완성된 후의 응용시스템의 보정요소

DEL : 유지보수프로젝트에 의해 삭제될 기능들의 보정전 기능점수

VAFB : 유지보수프로젝트가 시작되기 전 응용시스템의 보정요소

 

③ 응용시스템 기능점수 계산

응용시스템의 초기 기능점수 계수는 다음 식에 의해 계산된다. 초기에는 기능에 대한 변경이나 삭제 등이 없으므로 전환요구사항도 없는 상태이다.

AFP = ADD * VAF

AFP : 응용시스템의 초기 기능점수 계수

ADD : 개발프로젝트에 의해 설치된 기능들의 보정전 기능점수

VAF : 응용시스템의 보정요소

유지보수프로젝트에 의해 변경된 응용시스템이 설치되면 응용시스템의 기능점수도 변경되어야 한다. 응용시스템의 기능점수 계수는 다음 식에 의해 계산된다.

AFP = [(UFPB + ADD + CHGA) – (CHGB + DEL)] * VAFA

AFP : 응용시스템의 보정된 기능점수 계수

UFPB : 유지보수프로젝트가 시작되기 전 응용시스템의 보정전 기능점수계수

ADD : 유지보수프로젝트에 의해 추가된 기능들의 보정전 기능점수계수

CHGA : 유지보수프로젝트에 의해 수정된 기능들의 보정전 기능점수계수. CHGA는 수정후의 기능점수 계수를 나타낸다.

CHGB : 유지보수프로젝트에 의해 수정된 기능들의 보정전 기능점수계수. CHGA는 수정이 발생하기 전의 기능점수 계수를 나타낸다.

DEL : 유지보수프로젝트에 의해 삭제된 기능들의 보정전 기능점수계수.

VAFA : 유지보수프로젝트 종료후에 응용시스템의 보정된 기능점수계수

 

 

제 5장 COCOMO

COCOMO(Constructive Cost Model)는 Dynamic Based 소프트웨어 비용산정 기술(Software Estimation Techniques)의 하나로 볼 수 있다. COCOMO 중심의 모델은 COCOMOⅠ, COCOMOⅡ, COCOMOⅡ 재사용, 그리고 상용 컴포넌트 중심의 모델인 COCOTS 등이 있다. 이들 중 최근 정보기술 동향을 고려하여 객체지향 기반의 개발방법론과 컴포넌트 기반의 개발방법론을 지원하는 COCOMOⅡ와 COCOTS 모델을 중심으로 살펴보려고 한다.

1981년 Barry Boehm에 의하여 창시된 오리지날 COCOMO 모델(COCOMOⅠ)은 과거 구조적 방법론에 적용이 가능한 비용산정 모델이었다. 개발 방법론이 구조적 개발 방법론에서 객체지향 기반의 개발 방법론으로 변화됨에 따라 소프트웨어 개발비용 산정모델도 오리지날 COCOMOⅠ에서 COCOMOⅡ라는 새로운 모델로 발전되었다.

 

 

5.1 COCOMOⅡ

 

5.1.1 개요

COCOMOⅡ는 크게 COCOMOⅡ 응용 조합 모델(Application Composition Model), 설계단계 이전 모델(Early Design Model), 그리고 구조구현 후 모델(Post-Architecture Model)로 분류되어진다. 다음과 같이 각각의 특징을 알아보고 소프트웨어 비용산정에 영향을 미치는 각 모델의 원가요소에 대하여 알아본다.

 

(1) COCOMOⅡ 응용 조합 모델(Application Composition Model)

이 모델은 소프트웨어 생명주기 나선형(spiral) 모델의 초기 단계에서 시제품 개발시 적용할 수 있는 모델이므로 개략적인 개발 노력도 예측에 적용할 수 있다.

 

(2) 설계단계 이전 모델(Early Design Model)

이 모델은 모든 것이 명확하지 않고 소프트웨어 개발에 대한 데이터가 충분하지 않은 소프트웨어의 초기 개발 단계에서 대략적인 개발 노력도를 예측하는데 사용한다. 개발되는 소프트웨어의 규모(size), 설치될 플랫폼의 성격, 사용될 개발 프로세스의 사양 등이 개략적으로 알려진 프로젝트의 초기단계에 적용될 수 있는 모델이다. 또한 COCOMOⅡ는 기능점수 개념을 활용하고 있으며 노력승수(EM, Effort Multiplier)에서는 7가지 원가요소(cost drivers)를, 비례요인(SF, Scale Factor)에서는 5가지 원가요소를 제시하고 있다.

 

(3) 구조구현 후 모델(Post-Architecture Model)

이 모델은 설계단계 이전 모델(early design model)보다 좀 더 정교한 실제적인 소프트웨어 개발 노력도와 나아가서는 유지보수 노력도까지를 측정할 수 있는 모델이다. 이 모델은 이미 소프트웨어 개발 생명주기의 구조구현 단계가 종료되었을 경우에 적용되면, 개발 비용을 산정하는데 매우 효과적이다. 노력승수(EM, Effort Multiplier)의 17가지 원가요소(cost drivers)와, 비례요인(SF, Scale Factor)을 결정하는 5가지 원가요소를 제시하고 있다.

이 세 가지 모델은 현재의 개발 단계가 어디에 있느냐에 따라서 구분 적용하므로 COCOMOⅡ 모델을 효율적으로 활용할 수 있는 방법의 하나이다.

 

5.1.2 원가요소(cost drivers)

 

(1) 설계단계 이전 모델의 노력승수(EM)

1) RCPX(Product Reliability and Complexity)

2) RUSE(Developed for Reusability)

3) PDIF(Platform Difficulty)

4) PERS(Personal Capability)

5) PREX(Personnel Experience)

6) SCED(Required Development Schedule)

7) FCIL(Facilities)

 

(2) 설계단계 이전 모델과 구조구현 후 모델의 비례요인(SF)

1) 경험도(Precedentedness: PREC)

2) 개발의 유연성(Development Flexibility: FLEX)

3) 아키텍쳐/위험 해결성(Architecture/Risk Resolution: RESL)

4) 팀의 결속력(Team Cohesion: TEAM)

5) 프로세스 성숙도(Process Maturity: PMAT)

 

(3) 구조구현 후 모델의 노력승수(EM)

17가지 원가요소(cost drivers)들을 소프트웨어 제품관련 요소, 플랫폼 성능 제약 관련 요소, 투입 인력 관련 요소, 프로젝트 관리 관련 요소 등으로 분류하여 볼 수 있다.

 

(가) Product Drivers

1) RELY(required software reliability)

2) DATA(database size)

3) CPLX(product complexity)

4) RUSE(required reusability)

5) DOCU(documentation match to life-cycle needs)

(나) Platform Drivers

6) TIME(execution time constraint)

7) STOR(main storage constraint)

8) PVOL(platform volatility)

(다) Personnel Drivers

9) ACAP(analyst capabilities)

10) PCAP(programmer capabilities)

11) PCON(personnel continuity)

12) APEX(applications experience)

13) LTEX(language and tool experience)

14) PLEX(platform experience)

(라) Project Drivers

15) TOOL(use of software tools)

16) SITE(multisite development)

17) SCED(required development schedule)

 

COCOMOⅡ 모델에서는 각 원가요소들에 대해 5단계(Very Low, Low, Nominal, High, Very High) 판단등급(rating level)으로 평가하도록 구분하고 있다. 특별한 경우 Extra Low와 Extra High를 추가하여 7단계까지 판단하는 경우도 있다.

모델은 각 단계등급마다 기본적인 판단기준을 제시하고 있다. 7단계 평가 결과에 따라 응용 소프트웨어 개발비용 산정 결과에 영향을 미치고 있다.

먼저 소스코드의 크기(module size, total lines of code)를 측정하고, 구분 평가된 원가요소(cost drivers)별 평가단계값을 반영하여 노력승수(EM)를 측정하여 노력도(PM: person month)를 계산해 낸다. 이 노력도에 노임단가(labor rate, $/month)를 반영하여 소프트웨어 개발비용을 산정한다.

 

5.1.3 원가요소별 판단등급 구분기준과 노력승수

COCOMOⅡ. 2000 의 설계단계 이전 모델, 구조구현 후 모델의 원가요소(cost driver)와 비례요인(scale factor)의 구분설명과 노력도 산정에 반영하는 노력승수(effort multiplier) 부여값을 살펴보면 다음과 같다. 노력승수의 값이 클수록 노력도의 값도 커져 소프트웨어 개발비용을 증가시키는 요인이 된다.

 

(1) 구조구현 후 모델의 원가요소(cost drivers)

1) RELY(required software reliability)

사용자의 소프트웨어 신뢰성 요구정도

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

slight

inconvenience

low, easily recoverable loses

moderate,easily

recoverable loses

high

financial loss

risk to

human life

노력승수

0.82

0.92

1.00

1.10

1.26

2) DATA(database size)

데이터베이스의 정량적 크기를 고려하여 노력도를 산정하는 판단등급을 구분한다.

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

n/a

(testing DB bytes / Pgm SLOC)<10

10≤D/P<100

100≤D/P<1000

D/P>1000

노력승수

n/a

0.90

1.00

1.14

1.28

(SLOC : source line of code)

3) CPLX(product complexity)

소프트웨어 제품의 복잡성은 다섯 영역으로 나누어 진다.

통제운영, 계량적 운영, 운영의 Input/Output Device 의존성, 자료관리 운영, 사용자 인터페이스 관리 운영 등의 영역별로 판단등급(rating levels)기준이 존재한다.

판단등급

Very Low

Low

Nominal

High

Very High

노력승수

0.73

0.87

1.00

1.34

1.74

4) RUSE(required reusability)

다른 응용에 재사용할 수 있는 정도

판단등급

Very Low

Low

Nominal

High

Very High

Extra High

구분기준

n/a

none

accross project

accross program

accross product line

accross multiple product line

노력승수

n/a

0.95

1.00

1.07

1.15

1.24

5) DOCU(documentation match to life-cycle needs)

개발 단계마다의 산출물 문서화의 적합성

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

many lifecycle needs uncovered

some lifecycle needs uncovered

correct amount for lifecycle needs

excessive for lifecycle needs

very excessive for lifecycle needs

노력승수

0.81

0.91

1.00

1.11

1.23

6) TIME(execution time constraint)

이용가능 실행시간 사용정도

판단등급

Low

Nominal

High

Very High

Extra High

구분기준

n/a

≤50% use of available execution time

70% use

85% use

95% use

노력승수

n/a

1.00

1.11

1.29

1.63

7) STOR(main storage constraint)

이용가능 주기억장치의 사용정도

판단등급

Low

Nominal

High

Very High

Extra High

구분기준

n/a

≤50% use of available storage

70% use

85% use

95% use

노력승수

n/a

1.00

1.05

1.17

1.46

8) PVOL(platform volatility)

소프트웨어 제품의 개발에 사용되는 하드웨어와 소프트웨어(OS, DBMS, etc.) 변경의 정도

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

n/a

major change

every 12 months; minor change every 1 month

major: 6 months;

minor: 2 weeks

major: 2 months;

minor: 1 week

major: 2 weeks;

minor: 2 days

노력승수

n/a

0.87

1.00

1.15

1.30

9) ACAP(analyst capabilities)

관련 또는 유사분야 상위분석과 상세분석 업무 수행경험의 정도

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

15th percentile

35th percentile

55th percentile

75th percentile

90th percentile

노력승수

1.42

1.19

1.00

0.85

0.71

10) PCAP(programmer capabilities)

개발팀 프로그래머들 능력의 정도. 개발 대상 시스템을 이해하고 협력하여 프로젝트를 진행할 수 있는 능력을 말하는 것으로 개인의 능력보다는 팀으로서 프로그래머들의 능력에 기초하여 판단하게 되는 원가요소로 볼 수 있다.

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

15th percentile

35th percentile

55th percentile

75th percentile

90th percentile

노력승수

1.34

1.15

1.00

0.88

0.76

11) PCON(personnel continuity)

소프트웨어 개발 프로젝트의 연간 인력 회전율의 정도로 3 %이하의 인력 회전율이 Very High 계속성이고, 48% 이상이면 Very Low 계속성으로 보고 있다. 한 번 투입된 인력이 프로젝트 기간중 변동되지 않고 계속 투입되는 것이 소프트웨어 개발 생산성 유지/향상과 함께 전체 프로젝트 추진효율을 높일 수 있음은 소프트웨어 개발 현장에서 실증되고 있는 사항이다.

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

48%/year

24%/year

12%/year

6%/year

3%/year

노력승수

1.29

1.12

1.00

0.90

0.81

12) APEX(applications experience)

소프트웨어 개발팀원들이 동일 또는 유사 성격의 응용 소프트웨어 시스템이나 서브시스템 개발경험 보유의 정도

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

≤2months

6months

1year

3years

6years

노력승수

1.22

1.10

1.00

0.88

0.81

13) LTEX(language and tool experience)

소프트웨어 개발팀원들이 프로젝트에 필요한 개발언어 사용경험, 구현능력 수준의 정도

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

≤2months

6months

1year

3years

6years

노력승수

1.20

1.09

1.00

0.91

0.84

14) PLEX(platform experience)

개발 참여자들이 강력한 플랫폼(graphic user interface, database, networking, 분산미들웨어 기능 등을 포함)의 사용에 대한 이해 및 개발 생산성에 영향을 미칠 수 있는 플랫폼 경험의 정도

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

≤2months

6months

1year

3years

6years

노력승수

1.19

1.09

1.00

0.91

0.85

15) TOOL(use of software tools)

프로젝트 진행에 소프트웨어 도구 적용의 정도

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

edit,code, debug

simple,

frontend,

backend CASE,

little integration

basic life cycle tools,

moderately integrated

strong mature life cycle tools,

moderately integrated

strong, mature, proactive life cycle tools,

well integrated with processes,

methods, reuse

노력승수

1.17

1.09

1.00

0.90

0.78

16) SITE(multisite development)

소프트웨어를 개발하는 사이트의 숫자는 개발효율에 영향을 미친다. 코코모Ⅱ에서는 사이트 원가요소를 사이트위치와 의사소통수단으로 구분하여 판단할 수 있도록 하고 있다.

판단등급

Very Low

Low

Nominal

High

Very High

Extra High

구분기준

(collocation)

Inter-

national

Multi-city and Multi- company

Multi-city or Multi-

company

Same city or metro. area

Same building or complex

Fully

collocated

구분기준

(commu-

nications)

Some phone, mail

Individual phone, FAX

Narrow band e-mail

Wideband electronic commu-

nication

Wideband electronic commu-

nication,

occasional video conf.

Interactive

multimedia

노력승수

1.22

1.09

1.00

0.93

0.86

0.80

17) SCED(required development schedule)

프로젝트에서 요구하는 개발일정의 연장 또는 단축의 정도

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

75% of nominal

85% of nominal

100% of nominal

130% of nominal

160% of nominal

노력승수

1.43

1.14

1.00

1.00

1.00

 

 

(2) 설계단계 이전 모델(early design model)의 원가요소(cost drivers)

1) RCPX(Product Reliability and Complexity)

이 원가요소는 구조구현 단계 후 모델의 원가요소인 소프트웨어 신뢰성(RELY), 데이터베이스 크기(DATA), 제품의 복잡성(CPLX), 개발 각 단계에서 필요로 하는 산출물 문서화의 적정성(DOCU)과 결합된다.

RELY, DOCU는 Very Low에서 Very High까지 판단등급 범위이고, DATA는 Low에서 Very High까지 범위, CPLX는 Very Low에서 Extra High까지 범위로 되어 있다. 이 네 가지 원가요소의 판단결과를 집계하여 최저점 5(VL, L, VL, VL)에서 최고점 21(VH, VH, EH, VH)까지 부여할 수 있다.

판단등급

Extra High

Very Low

Low

Nominal

High

Very High

Extra High

구분기준

– Sum of RELY,DATA, CPLX,DOCU ratings

– Emphasis on reliability, documentation

– Product complexity

– Database size

5,6

Very Little

Very simple

Small

7,8

Little

Simple

Small

9-11

Some

Some

Small

12

Basic

Moderate

Moderate

13-15

Strong

Complex

Large

16-18

Very Strong

Very complex

Very Large

19-21

Extreme

Extremely complex

Very Large

노력승수

0.49

0.60

0.83

1.00

1.33

1.91

2.72

 

2) RUSE(Developed for Reusability)

다른 응용에 재사용할 수 있는 정도로, 구조구현 후 모델(post-architecture model)의 원가요소 RUSE와 동일하다.

판단등급

Very Low

Low

Nominal

High

Very High

Extra High

구분기준

n/a

none

accross project

accross program

accross product line

accross multiple product line

노력승수

n/a

0.95

1.00

1.07

1.15

1.24

 

3) PDIF(Platform Difficulty)

이 원가요소는 구조구현 단계 후 모델의 원가요소인 실행시간 제약의 정도(TIME), 주기억장치 제약의 정도(STOR), 개발에 사용되는 플랫폼 변경의 정도(PVOL) 등 세 가지 요소와 결합된다.

TIME, STOR는 Nominal에서 Extra High까지가 판단등급 범위이고, PVOL는 Low에서 Very High까지 범위로 되어 있다. 이 세 가지 원가요소의 판단결과를 집계하여 최저점 8(N, N, L)에서 최고점 17(EH, EH, VH)까지 부여할 수 있다.

판단등급

Low

Nominal

High

Very High

Extra High

구분기준

– Sum of TIME, STOR, and PVOL ratings

– Time and storage constraint

– Platform volatility

8

≤50%

Very stable

9

≤50%

Stable

10-12

65%

Somewhat volatile

13-15

80%

Volatile

16,17

90%

Highly volatile

노력승수

0.87

1.00

1.29

1.81

2.61

 

4) PERS(Personal Capability)

설계단계 이전 모델의 PERS 원가요소는 구조구현 단계 후 모델의 원가요소인 시스템 분석가의 능력(ACAP), 개발에 투입된 프로그래머의 능력(PCAP), 투입된 인력의 계속성(PCON) 등 세 가지 요소와 결합된다.

이 세 가지 원가요소는 Very Low(= 1)에서 Very High(= 5)까지가 판단등급 범위이다. 이 세 가지 원가요소의 판단결과를 집계하여 최저점 3에서 최고점 15까지 부여할 수 있다.

판단등급

Extra High

Very Low

Low

Nominal

High

Very High

Extra High

구분기준

– Sum of ACAP, PCAP, PCON ratings

– Combined SCAP and PCAP percentile

– Annual Personnel Turnover

3,4

20%

45%

5,6

35%

30%

7,8

45%

20%

9

55%

12%

10,11

65%

9%

12,13

75%

6%

14,15

85%

4%

노력승수

2.12

1.62

1.26

1.00

0.83

0.63

0.50

 

5) PREX(Personnel Experience)

설계단계 이전 모델로 투입 인력의 경험정도(PREX) 원가요소는 구조구현 단계 후 모델(post-architecture model)의 원가요소인 개발자의 관련 응용시스템 경험(APEX), 개발에 투입된 인력의 개발언어와 개발도구 경험의 정도(LTEX), 투입된 인력의 관련 플랫폼 경험의 정도(PLEX) 등 세 가지 요소의 결합으로 볼 수도 있다.

이 세 가지 원가요소는 Very Low(= 1)에서 Very High(= 5)까지가 판단등급 범위이고, 이 세 가지 원가요소의 판단결과를 집계하여 최저점 3에서 최고점 15까지 부여할 수 있다.

판단등급

Extra High

Very Low

Low

Nominal

High

Very High

Extra High

구분기준

– Sum of APEX, PLEX, LTEX ratings

– Applications, Platform, Language and Tool Experience

3,4

≤3

months

5,6

5

months

7,8

9

months

9

1

year

10,11

2

years

12,13

4

years

14,15

6

years

노력승수

2.12

1.62

1.26

1.00

0.83

0.63

0.50

 

6) SCED(Required Development Schedule)

프로젝트에서 요구하는 개발일정의 연장 또는 단축의 정도로 구조구현 후 모델(post-architecture model)의 원가요소 SCED와 동일하다.

판단등급

Very Low

Low

Nominal

High

Very High

구분기준

75% of nominal

85% of nominal

100% of nominal

130% of nominal

160% of nominal

노력승수

1.43

1.14

1.00

1.00

1.00

 

7) FCIL(Facilities)

설계단계 이전 모델로 프로젝트 추진 관련 설비의 정도(FCIL) 원가요소는 구조구현 단계 후 모델(post-architecture model)의 원가요소인 소프트웨어 도구의 사용(TOOL), 개발장소의 수와 위치(SITE) 등 두 가지 요소의 결합으로 볼 수도 있다.

TOOL 원가요소는 Very Low부터 Very High까지, SITE는 Very Low에서 Extra High까지가 판단등급 범위이다. 이 두 가지 원가요소의 판단결과를 집계하여 최저점 2(VL, VL)에서 최고점 11(VH, EH)까지 부여할 수 있다.

판단등급

Extra High

Very Low

Low

Nominal

High

Very High

Extra High

구분기준

– Sum of TOOL and SITE ratings

– TOOL support

– Multisite conditions

2

Minimal

Weak support of complex multisite(M/S) develo-pment

3

Some

Some supportof complex M/S develo-pment

4,5

Simple CASE tool collection

Some support of modera-

tely complex M/S develo-

pment

6

Basic life cycle tools

Basic support of modera-tely complex M/S develo-

pment

7,8

Good; modera- tely integra-

ted

Strong support of modera-

tely complex M/S develo-

pment

9,10

Strong; modera- tely integra-

ted

Strong support of simple M/S develo-

pment

11

Strong; Well integrated

Very strong support of collocated or simple M/S develo-

pment

노력승수

1.43

1.30

1.10

1.00

0.87

0.73

0.62

 

(3) 비례요인(scale factors)

비례요인에는 경험도(PREC), 개발의 유연성(FLEX), 아키텍쳐/위험 해결성(RESL), 팀의 결속력(TEAM), 프로세스 성숙도(PMAT) 등 다섯 가지로 구성되어 있다. 비례요인의 값이 클수록 소프트웨어 개발비용이 증가되는 요인이 된다.

 

1) 경험도(Precedentedness: PREC)

현재 추진중인 프로젝트와 유사한 개발프로젝트 참여 경험이 다양할수록 경험도는 높아진다. 투입 인력들의 프로젝트 관련 경험도가 높을 경우 소프트웨어 개발비용은 감소될 수 있다.

 

– 제품목적의 조직적 이해도

– 관련된 소프트웨어 시스템의 작업 경험의 정도

– 관계된 새로운 하드웨어와 운영절차의 동시개발 정도

– 혁신적인 자료처리구조,알고리즘의 필요성

판단등급

Very

Low

Low

Nominal

High

Very High

Extra High

구분기준

thoroughly unprece-

dented

largely unprece-

dented

somewhat unprece-

dented

generally familiar

largely familiar

thoroughly

familiar

비례요인

6.20

4.96

3.72

2.48

1.24

0.00

 

2) 개발의 유연성(Development Flexibility: FLEX)

주어진 시스템 요구사항, 예산, 일정계획 등의 유연성으로 프로젝트 본질적이고 통제하기가 어려운 요소이다.

– 기 설정된 소프트웨어요구사항에 대한 순응의 필요성 정도

– 외부 시스템과의 연계사양에 순응 필요성 정도

– 기성고부분 비융통성과의 결합의 정도

판단등급

Very

Low

Low

Nominal

High

Very High

Extra High

구분기준

rigorous

occasional relaxation

some relaxation

general conformity

some conformity

general goals

비례요인

5.07

4.05

3.04

2.03

1.01

0.00

 

3) 아키텍쳐/위험 해결성(Architecture/Risk Resolution: RESL)

프로젝트 진행중 주요한 위험항목의 존재 여부와 해결의 능력을 예상할 수 있는 요소들을 고려하여 구분기준을 판단함으로써 소프트웨어 개발비용 산정에 반영할 수 있다.

– 모든 주요 위험항목에 대한 위험관리계획의 수립, 라이프사이클상 위험해결 마일스톤이 정립되어 있는 정도

– 위험관리계획과 양립할 수 있는 일정계획, 예산, 내부 마일스톤의 정도

– 전체 개발일정 중 주어진 제품의 목적에 적합한 아키텍처 설정에 부여된 일정의 차지비율

– 프로젝트에 활용가능한 최고 소프트웨어 설계자의 요청 대 실제 활용비율

– 위험항목의 해결, 구조적 사양의 검증과 개발 등에 이용가능한 도구지원 정도

– 위험항목의 중요성과 숫자 등

판단등급

Very

Low

Low

Nominal

High

Very High

Extra High

구분기준

little

(20%)

some

(40%)

often

(60%)

generally

(75%)

mostly

(90%)

full

(100%)

비례요인

7.07

5.65

4.24

2.83

1.41

0.00

 

4) 팀의 결속력(Team Cohesion: TEAM)

프로젝트 팀을 구성하고 있는 관련자들(사용자, 고객, 개발자, 유지보수담당자, 상호연계 관련자 등)의 능력, 속성을 보여주는 판단기준항목들을 고려하여 소프트웨어 개발비 산정에 반영하게 된다. 프로젝트 관련자들이 상호 협력적인가, 비협조적인가 여부가 관건이 된다.

– 프로젝트 관련자들이 가진 목적과 문화의 계속성

– 다른 관련자들의 목적 의견을 수용 조정하는 프로젝트 관련자들의 능력, 의지

– 프로젝트 추진 관련자들의 팀 운영경험의 정도 등

판단등급

Very

Low

Low

Nominal

High

Very High

Extra High

구분기준

very difficult interactions

some difficult interactions

basically cooperative interactions

largely

cooperative

highly cooperative

seamless interactions

비례요인

5.48

4.38

3.29

2.19

1.10

0.00

 

5) 프로세스 성숙도(Process Maturity: PMAT)

프로세스 성숙도를 검토하여 소프트웨어 개발비 산정에 반영하기 위하여 전반적인 성숙도 수준의 평가와 주요 프로세스 영역에 대한 설문의 결과 크게 두 가지로 구분하여 판단등급을 결정하게 된다. 프로세스 성숙도는 SEI(software engineering institute)의 성숙도 모델인 CMM(capability maturity model)의 성숙도 수준(maturity level)에 따라 판단한다.

 

주요 프로세스 영역 설문(key process area questionnaire)은 요구사항 관리(requirements management), 소프트웨어 개발 추진계획(software project planning), 소프트웨어 개발 관련 부속계약관리(software subcontract management), 소프트웨어 품질보증(software quality assurance), 소프트웨어 구성항목 관리(software configuration management) 등을 주요프로세스 영역으로 하여 설문을 구성하여 판단기준을 도출할 수 있다.

 

판단등급

Very

Low

Low

Nominal

High

Very High

Extra High

구분기준

SW-CMM

Level 1 Lower

SW-CMM

Level 1 Upper

SW-CMM

Level 2

SW-CMM

Level 3

SW-CMM

Level 4

SW-CMM

Level 5

또는 산정되는 프로세스 성숙도 수준 적용

비례요인

7.80

6.24

4.68

3.12

1.56

0.00

 

5.2 COCOMOⅡ 재사용 모델

 

5.2.1 개요와 주요 원가요소

기 개발경험이 있는 유사 프로젝트의 개발시 대부분의 개발업체에서는 과거의 프로젝트를 재사용하여 개선해 가는 경우가 사실상 많이 발생한다. 이러한 부분을 고려하여 개발 노력도를 산정하고자 생긴 것이 COCOMOⅡ의 재사용 모델이다. 이 모델 역시 COCOMOⅡ를 기본 모델로 하고 있다.

 

COCOMOⅡ 모델에서는 디자인 변형률(percent design modified), 코드 변형률(percent code modified), 통합률(percent of integration required for adapted software) 등을 주요 요소로 노력도를 산정해 낸다. 그러나 이러한 과정은 매우 복잡하여 실무적 차원에서 적용하기에는 어려움이 많다.

 

5.3 COCOTS(COnstructive COTS) 모델

 

5.3.1 개요

COTS는 commercial off the shelf의 약자로 기 완성품으로 개발되어서 상용화되어 이용가능한 소프트웨어 컴포넌트를 말한다. 상용 컴포넌트 통합 노력도에 관한 모델로 COCOMOⅡ 모델에서 파생된 COCOTS 모델이 최근에 출현하였는데, 현재 COCOTS 모델에서는 개발과정의 노력도만이 측정 가능하다. 그러나 향후 COCOTS 모델에서는 소프트웨어 유지보수에 대한 노력도도 추가적으로 산정이 가능할 것으로 본다[8].

상용 컴포넌트(COTS) 제품은 몇 가지 특징을 가지고 있는데, 첫째로 상용 컴포넌트를 구입한 사람은 본래의 상용 컴포넌트의 기능이나 수행 방법을 바꿀 수 있다는 점이고, 둘째는 대부분의 상용 컴포넌트 제품은 서로 쉽게 연결할 수 없다는 점이고, 셋째로 구매자는 상용 컴포넌트의 업그레이드에 직접적으로 관여할 수 없다는 점이며, 마지막으로 상용 컴포넌트 제작사의 특성은 다양하다는 점이다.

 

상용 컴포넌트 제품이 가진 위험성에는 대체적으로 상용 컴포넌트 제작사의 미성숙성, 상용 컴포넌트 사용자의 경험 미숙, 기반환경과 제품간의 비 호환성, 사용자가 상용 컴포넌트 제품에 대하여 현재 혹은 향후 변경을 할 수 없음, 대부분의 사용자가 상용 컴포넌트 제품 조립시 Plug-and-Play로 단순히 생각함 등을 예로 들 수 있다. 그러나 이러한 위험성들은 자격 테스팅(qualification testing), 벤치마킹(benchmarking), 참조 체크(reference checking), 호환성 분석(compatibility analysis) 등의 단계를 통하여 감소시킬 수 있는 가능성은 있다.

 

COCOTS 모델은 다음과 같이 5가지의 과정을 가지고 있다.[9]

1) 상용 컴포넌트 후보 평가 및 선정과정

2) 상용 컴포넌트 맞춤 및 튜닝과정

3) 선정된 상용 컴포넌트들의 통합 및 조립과정

4) 조립된 소프트웨어 테스트 과정

5) 운영과 유지보수 과정

 

기존의 응용소프트웨어 개발은 거의가 자체 개발 또는 시스템개발전문 업체에 위탁하는 주문 제작형이었다. 주무 제작할 경우, 소스코드가 공개되어 재사용시 변형이 가능하다는 장점이 있다. 반면에, 상용 컴포넌트 환경에서의 개발은 소프트웨어의 모든 부분을 부품화 개념으로 필요한 부분을 즉시 구입하여 사용하므로 가격과 시간이 많이 절약되는 장점이 있다. 그러나 상용 컴포넌트 환경이라고 모든 부품이 시장에 있는 것은 아니다.

때에 따라서는 불가피하게 자체에서 기존과 같이 개발하거나 고객화(customizing)해야만 하는 부분이 있다. 그러므로 결국 완전한 상용 컴포넌트 환경은 아직까지 현실에 맞지 않으므로 개발 노력도(비용)를 예측할 때는 다음 [그림 5.1]과 같이 두 가지 모형으로 분리하여 측정하여야 한다. 그러나 이것은 과다한 정보를 요구하므로 업계의 현실에 맞지 않는다는 점이 이 모델을 적용하기 곤란한 점으로 지적되고 있다.

5.3.2 COCOTS의 원가요소

(1) 컴포넌트 제품의 성숙도

(2) 컴포넌트 제품에 대한 접착자의 경험

(3) 컴포넌트 접착자의 능력

(4) 컴포넌트 접착자의 통합에 대한 경험

(5) 컴포넌트 접착자의 지속성

(6) 컴포넌트 공급자의 제품 확장에 대한 의지

(7) 컴포넌트 제품의 상호 호환의 복잡성

(8) 컴포넌트 제작사의 지원

(9) 컴포넌트 제작사의 교육과 설명서 제공

(10) 개발할 응용시스템에 대한 제한 및 하위시스템의 신뢰성

(11) 개발할 응용시스템의 호환상의 복잡성

(12) 컴포넌트의 기술적 성능에 대한 제약성

(13) 개발할 응용시스템의 이동성

 

5.4 USC COTS 모델

 

5.4.1 개요

USC(University of Southern California)의 소프트웨어 공학센터에서 개발한 상용 컴포넌트 통합 노력도를 연구한 모델이 있는데 편의상 USC COTS 모델이라 부른다. 이 모델은 COCOMO 모델을 기반으로 상용 컴포넌트 통합 노력도 산정을 위한 모델로 개선해 놓은 모델이다. USC COTS 모델은 COCOMOⅡ의 재사용 모델을 기반으로 하고 있다.

 

5.4.2 원가요소

USC COTS 모델은 노력승수의 원가요소로 13가지를 만들었다.

(1) 상용 컴포넌트 제품 및 매뉴얼의 성숙도(CPDM)

(2) 상용 컴포넌트 공급자의 제품 확장에 대한 의지(CVEW)

(3) 상용 컴포넌트 제품에 대한 접착자의 경험(CIEP)

(4) 상용 컴포넌트의 신뢰성(CREL)

(5) 상용 컴포넌트 제품과 응용에 대한 복잡성(CPAX)

(6) 상용 컴포넌트 접착자의 능력(CIPC)

(7) 상용 컴포넌트 통합 구조 및 위험부담 해결성(CIAR)

(8) 상용 컴포넌트 개발 호환의 표준에 대한 순응성(CCOS)

(9) 상용 컴포넌트의 성능(CPER)

(10) 상용 컴포넌트 통합자의 COTS 통합에 대한 경험(CIXI)

(11) 상용 컴포넌트 제공자의 성숙도와 제품에 대한 지원(CVMS)

(12) 상용 컴포넌트 제공자의 교육(CVPT)

(13) 컴포넌트의 이동성(CPRT)

 

 

 

제 6 장 원가산정요소 효과와 관련성 분석

소프트웨어 개발비용 산정 방식들이 채택하고 있는 원가산정요소(비용요소)들을 비교하며, 산정방식들이 공통적으로 사용하거나 주요한 요소로 판단되는 원가산정요소들을 분석해 보고자 한다.

 

6.1 원가산정요소 비교

 

6.1.1 설계단계 이전 적용가능요소와 구현 단계 적용가능요소

일반 응용시스템 개발에 있어서 소프트웨어 개발비용 산정의 시점이 언제인가에 따라 적용할 수 있는 원가요소가 구분될 수 있다. 구현 이후에는 정성적은 물론이고 정량적으로 명확히 파악할 수 있는 요소가 설계 이전 단계에서는 예상요소로 개략적 파악 정도까지 가능하기 때문이다. COCOMOⅡ의 설계단계(Early Design) 이전 모델과 구조구현 후(Post-Architecture) 모델의 원가요소를 비교해 보면 [표 6.1]과 같다.

 

설계단계 이전 모델 적용 원가요소와 구조구현 이후 모델에서 적용하는 원가요소를 비교해보면 두 시점에 모두 적용되는 동일한 성격의 원가요소를 발견할 수 있다.

– 제품의 신뢰성/복잡성 RCPX와 CPLX, RELY, DATA, DOCU

– 재사용성 RUSE와 RUSE

– 플랫폼 제약 PDIF와 TIME, STOR, PVOL

– 투입인력의 능력 PERS와 ACAP, PCAP, PCON

– 투입인력의 경험 PREX와 APEX, LTEX, PLEX

– 개발 일정계획 SCED와 SCED

– 프로젝트 추진인프라 FCIL와 TOOL, SITE

 

두 시점에 적용되는 모델에 결합되어 나타나는 위의 요소들은 소프트웨어 개발비용을 산정할 때 필수 불가결한 요소로 고려되어야만 하는 요소로 볼 수 있다. 다만, 설계 이전 단계에서는 판단할 수 있는 각 요소의 구성내역을 상세히 정량적으로 알 수 없는 한계는 존재하지만, 전문가적 판단이나 산정되는 값을 예상해 내는 방법 등으로 비용산정 모델에서 이용하고 있다. 시스템의 구조 구현 이후에는 각 원가요소에 대한 객관적인 구성내역과 값을 적정하게 산정할 수 있으므로 소프트웨어 개발비용을 산정하는 데 큰 어려움 없이 활용될 수 있다.

구 분

COCOMOⅡ:

Early Design 원가요소

COCOMOⅡ:

Post-Architecture 원가요소

제품지향

원가요소

(Product

Cost Drivers)

1) 제품신뢰성과 복잡성

(RCPX : Product Reliability and Complexity)

2) 재사용성

(RUSE : Developed for

Reusability)

1) 소프트웨어 신뢰성 요구

(RELY : required software reliability)

2) 데이터의 크기

(DATA : database size)

3) 제품의 복잡성

(CPLX : product complexity)

4) 재사용성 요구

(RUSE : required reusability)

5) 산출물 적합성

(DOCU : documentation match to

life-cycle needs)

플랫폼지향

원가요소

(Platform

Cost Drivers)

3) 플랫폼 제약

(PDIF : Platform

Difficulty)

6) 실행시간 제약

(TIME : execution time

constraint)

7) 주기억장치 제약

(STOR : main storage constraint)

8) 플랫폼 변경의 정도

(PVOL : platform volatility)

인력지향

원가요소

(Personnel

Cost Drivers)

4) 투입인력의 능력

(PERS : Personal

Capability)

5) 투입인력의 실무경험

(PREX : Personnel

Experience)

9) 분석가의 능력

(ACAP : analyst capabilities)

10) 프로그래머의 능력

(PCAP : programmer capabilities)

11) 투입인력의 계속성

(PCON : personnel continuity)

12) 응용시스템 경험

(APEX : applications experience)

13) 개발언어와 도구 사용경험

(LTEX : language and tool

experience)

14) 플랫폼 사용경험

(PLEX : platform experience)

프로젝트지향 원가요소

(Project

Cost Drivers)

6) 요구되는 개발일정계획

(SCED : Required

Development Schedule)

7) 프로젝트추진인프라

(FCIL : Facilities)

15) 소프트웨어 도구의 사용

(TOOL : use of software tools)

16) 복수의 개발장소

(SITE : multisite development)

17) 개발일정계획

(SCED : required development

schedule)

 

6.1.2 COCOTS 와 USC COTS 모델의 원가요소

상용 컴포넌트로 불리어지는 소프트웨어 상용제품(COTS : commercial off the shelf)을 이용한 시스템 개발비용 산정에 적용될 수 있는 모델에는 COCOTS와 USC COTS 모델 등이 있다. COCOTS 모델의 노력승수(EM : effort multiplier)와 USC COTS 모델의 노력승수(EM)를 비교 요약하면 [표 6.2]와 같다.

 

두 모델의 원가요소를 통합하면 26개의 원가요소가 발생한다. 이중 양 모델에서 동시에 명확하게 정의하고 있는 원가요소가

– 컴포넌트 접착자의 능력

– 컴포넌트 공급자의 제품확장에 대한 의지

– 컴포넌트 통합자의 통합에 대한 경험

– 컴포넌트 제품에 대한 접착자의 경험

등 네 가지 요소가 있다. 또 이 네 가지 요소는 컴포넌트 사용자(접착자, 통합자) 지향의 요소 세 가지와 공급자 지향의 요소 한가지로 상용 컴포넌트의 개발비용을 산정하는데 고려하여야 할 필수적인 주요 요소로 볼 수 있다. COCOTS에서 컴포넌트 제작사의 교육과 지원, 개발할 응용시스템의 이동성과, USC COTS의 컴포넌트 제공자의 교육, 컴포넌트의 이동성도 유사한 성격의 원가요소 또는 상호 관련성이 있는 원가요소로 볼 수 있다.

 

COCOTS

USC COTS

(1) 컴포넌트 제품의 성숙도

(2) 컴포넌트 제품에 대한 접착자의 경험

(3) 컴포넌트 접착자의 능력

(4) 컴포넌트 접착자의 통합에 대한 경험

(5) 컴포넌트 접착자의 지속성

(6) 컴포넌트 공급자의 제품 확장에 대한 의지

(7) 컴포넌트 제품의 상호 호환의 복잡성

(8) 컴포넌트 제작사의 지원

(9) 컴포넌트 제작사의 교육과 설명서 제공

(10) 개발 할 응용시스템에 대한 제한 및 하위시스템의 신뢰성

(11) 개발할 응용시스템의 호환상의 복잡성

(12) 컴포넌트의 기술적 성능에 대한 제약성

(13) 개발할 응용시스템의 이동성

(1) 상용 컴포넌트 제품 및 매뉴얼의 성숙도

(2) 상용 컴포넌트 공급자의 제품 확장에 대한 의지

(3) 상용 컴포넌트 제품에 대한 접착자의 경험

(4) 상용 컴포넌트의 신뢰성

(5) 상용 컴포넌트 제품과 응용에 대한 복잡성

(6) 상용 컴포넌트 접착자의 능력

(7) 상용 컴포넌트 통합 구조 및 위험부담 해결성

(8) 상용 컴포넌트 개발 호환의 표준에 대한 순응성

(9) 상용 컴포넌트의 성능

(10) 상용 컴포넌트 통합자의 COTS 통합에 대한 경험

(11) 상용 컴포넌트 제공자의 성숙도와 제품에 대한 지원

(12) 상용 컴포넌트 제공자의 교육

(13) 컴포넌트의 이동성

 

COCOTS와 USC COTS 모델의 원가요소를 통합하면 26개의 요소가 되지만, 두 모델에서 똑같이 제시하고 있는 요소 네 가지를 고려하면 [표 6.3]과 같이 22개의 원가요소가 발생된다.

– 컴포넌트 제품의 성숙도

– 컴포넌트 제품에 대한 접착자의 경험

– 컴포넌트 접착자의 능력

– 컴포넌트 접착자의 통합에 대한 경험

– 컴포넌트 접착자의 지속성

– 컴포넌트 공급자의 제품 확장에 대한 의지

– 컴포넌트 제품의 상호 호환의 복잡성

– 컴포넌트 제작사의 지원

– 컴포넌트 제작사의 교육과 설명서 제공

– 개발할 응용시스템에 대한 제한 및 하위시스템의 신뢰성

– 개발 할 응용시스템의 호환상의 복잡성

– 컴포넌트의 기술적 성능에 대한 제약성

– 개발 할 응용시스템의 이동성

– 상용 컴포넌트 제품 및 매뉴얼의 성숙도

– 상용 컴포넌트의 신뢰성

– 상용 컴포넌트 제품과 응용에 대한 복잡성

– 상용 컴포넌트 통합 구조 및 위험부담 해결성

– 상용 컴포넌트 개발 호환의 표준에 대한 순응성

– 상용 컴포넌트의 성능

– 상용 컴포넌트 제공자의 성숙도와 제품에 대한 지원

– 상용 컴포넌트 제공자의 교육

– 컴포넌트의 이동성

 

두 모델의 결합된 노력승수 원가요소를 컴포넌트 제품 자체, 컴포넌트 제품의 공급자, 컴포넌트의 사용자와 컴포넌트를 이용하여 개발할 시스템 중심으로 [표 6.4]와 같이 분류할 수 있다([3]).

분 류

항 목

컴포넌트 제품의 성숙도

– 컴포넌트 제품의 상호 호환의 복잡성

– 컴포넌트의 기술적 성능에 대한 제약성

– 컴포넌트의 신뢰성

– 컴포넌트의 개방 호환의 표준에 대한 순응성

– 컴포넌트의 성능

– 컴포넌트의 이동성

컴포넌트 제작사의

지원도

– 컴포넌트 공급자의 제품 확장에 대한 의지

– 컴포넌트 제작사의 지원

– 컴포넌트 제작사의 교육과 설명서 제공

– 컴포넌트 제품 및 매뉴얼의 성숙도

– 컴포넌트 제공자의 성숙도와 제품에 대한 지원

– 컴포넌트 제공자의 교육

컴포넌트 접착자의

성숙도

– 컴포넌트 제품에 대한 접착자의 경험

– 컴포넌트 접착자의 능력

– 컴포넌트 접착자의 통합에 대한 경험

– 컴포넌트 접착자의 지속성

– 컴포넌트 통합구조 및 위험부담 해결성

개발 대상 시스템의

난해도

– 개발할 응용시스템의 이동성

– 개발할 응용시스템의 호환상의 복잡성

– 개발할 응용시스템에 대한 제한 및 하위시스템의 신뢰성

– 개발할 응용소프트웨어에 대한 복잡성

상용 컴포넌트의 접착/통합을 통해 요구되는 시스템을 개발할 경우, 개발비용 산정에 활용되는 원가요소를 네 가지로 분류해 볼 수 있다.

– 컴포넌트 제품의 성숙도

– 컴포넌트 제작사의 지원도

– 컴포넌트 접착자의 성숙도

– 개발 대상 시스템의 난해도

컴포넌트 제품의 성숙도가 높을수록, 컴포넌트 제작사의 지원도가 높을수록, 컴포넌트 접착자의 성숙도가 높을수록, 개발 대상 시스템의 난해도가 낮을수록 개발비용은 절감될 수 있음은 물론이다.

 

6.1.3 COCOMOⅡ와 Function Point 방식의 원가요소 비교

 

6.1.3.1 Function Point 모델의 원가요소

기능점수(function point) 방식의 특징은 사용언어, 개발자의 기술, 개발환경, 4GL과 상용 컴포넌트를 이용하는 경우 등과 같은 시스템 개발방법과는 직접 관련이 없고, 일관된 척도로 시스템의 가치를 평가하는 것이다. 이렇게 함으로써 종래의 프로그램 수나 소스코드(스텝수)에 의한 산정방식의 한계를 타파하고 있다. 완료된 프로젝트나 가동중인 시스템의 기능점수 실적치를 축적하여 개발공수와의 관계를 분석하면, 견적에도 응용 가능하게 된다.

 

기능점수 방식은 MIS 영역 이외의 영역 즉, real-time 소프트웨어에서는 잘 적용되고 있지 못하는 단점을 지니고 있다. 이를 개선하기 위해 IFPUG내에서는 FFP(full function point)를 계발 연구중에 있으며, 많은 부분에서 기존 기능점수 방식을 보완하고 있다.

기능점수 방식에서는 기능증대요인을 정보시스템원가 산정요소 즉, 원가요소로 볼 수 있다. 기능점수 계산은 기능증대요인의 수 및 요인별 난이도 가중치를 정하여 기본기능점수(BFP)를 구하고, 성능특성요소와 품질특성요소별 영향도를 합산하여 기술적 복잡도를 계산한다. 기본기능점수에 기술적복잡도를 반영하여 총기능점수(TFP)를 계산한다.

 

기능증대요인과 난이도 판정기준은 [표 6.5]과 같다.

분 류

단 순

보 통

복 잡

입 력

외부입력자료 유형의 종류가 매우 적음(1-2개)

외부입력자료 유형의 종류가 3-5개

외부입력자료 유형의 종류가 많음(6개 이상)

출 력

출력이 1-3행, 화면출력양식이 단순함

행이 4개 이상, 출력양식이 복잡하지 않음

출력행이 여러개, 화면출력 양식이 복잡함

입출력

입출력 자료 유형의 수가 적음(1-2개)

입출력 자료 유형의 수가 3-5개

입출력 자료 유형의 수가 여러개임

메 뉴

메뉴가 1-3개, 하위 레벨의 메뉴가 없음

메뉴가 4개 이상, 하위 레벨의 메뉴가 없음

메뉴가 10개 이상, 하위 레벨의 메뉴가 있음

출력보고서

출력보고서 양식이 단순함

출력보고서 양식이 보통임(출력파일 상호간의 관계가 복잡하지 않음)

출력보고서 양식이 복잡함(출력파일 상호간의 관계가 복잡함)

사용자

명령어

단순한 명령어

단순한 명령어와 적은 수의 사용자 입력변수

복잡한 명령어와 많은 수의 사용자 입력변수

외부루틴과의

인터페이스

외부루틴과의 인터페이스가 매우 적음

외부루틴과의 인터페이스가 어느정도 있음

외부루틴과의 인터페이스가 매우 빈번함

파일

데이터와 데이터 혹은 데이터․파일간의 논리적인 구조가 단순함

파일간의 논리적인 구조가 단순하지도 복잡하지도 않음

파일간의 논리적인 구조가 복잡함

 

기능증대요인별 난이도 판정기준에 의한 기능점수 산정시에 적용되는 난이도 가중치는 [표 6.6]과 같다.

기 능 증 대 요 인

기능증대요인별 난이도 가중치

단 순

보 통

복 잡

화 면

입 력

3

6

13

출 력

3

5

8

입 출 력

6

11

19

메 뉴

2

2

9

출 력 보 고 서

3

6

10

사 용 자 명 령 어

3

4

6

외부루틴과의 인터페이스

5

7

11

파 일

입 력

3

5

8

출 력

3

5

8

입 출 력

3

6

13

난이도 가중치에서 볼 수 있듯이, 기능증대요인별 복잡성이 클수록 가중치가 커져 기능점수 산

정시 높은 기능점수를 산정하는 결과를 가져오고, 결국은 응용시스템 개발비용의 증대를 가져오게 된다.

 

6.1.3.2 COCOMOⅡ와 Function Point 방식의 원가요소 비교

COCOMOⅡ의 구조구현 이후 모델

기능점수방식의 기능증대요인

구 분

원가요소

1) 화면 입력

2) 화면 출력

3) 화면 입출력

4) 화면 메뉴

5) 출력보고서

6) 사용자명령어

7) 외부루틴과의

인터페이스

8) 파일 입력

9) 파일 출력

10) 파일 입출력

제품지향

원가요소

(Product

Cost Drivers)

1) 소프트웨어 신뢰성 요구 (RELY : required software reliability)

2) 데이터의 크기(DATA : database size)

3) 제품의 복잡성(CPLX : product complexity)

4) 재사용성 요구(RUSE : required reusability)

5) 산출물 적합성(DOCU : documentation match to life-cycle needs)

플랫폼지향

원가요소

(Platform

Cost Drivers)

6) 실행시간 제약(TIME : execution time constraint)

7) 주기억장치 제약(STOR : main storage constraint)

8) 플랫폼 변경의 정도(PVOL : platform volatility)

인력지향

원가요소

(Personnel

Cost Drivers)

9) 분석가의 능력(ACAP : analyst capabilities)

10) 프로그래머의 능력(PCAP : programmer capabilities)

11) 투입인력의 계속성(PCON : personnel continuity)

12) 응용시스템 경험(APEX : applications experience)

13) 개발언어와 도구 사용경험(LTEX : language and tool experience)

14) 플랫폼 사용경험(PLEX : platform experience)

프로젝트지향 원가요소

(Project

Cost Drivers)

15) 소프트웨어 도구의 사용(TOOL : use of software tools)

16) 복수의 개발장소(SITE : multisite development)

17) 개발일정계획(SCED : required development schedule)

 

기능점수(function point) 방식의 원가요소와 COCOMOⅡ의 원가요소를 비교해 보고자 한다. 기능점수 방식이 완료된 프로젝트나 가동중인 시스템에 적용하는 것이 유용하고, 기능점수 실적치를 축적하여 개발공수와의 관계를 분석하면, 견적에도 응용 가능하게 되는 점과, MIS 영역 이외의 영역 즉, real-time 소프트웨어에서는 잘 적용되고 있지 못하는 점을 고려하면 COCOMOⅡ의 구조구현 이후(post-architecture) 모델의 원가요소와 비교하는 것이 적절할 것이다.

 

COCOMOⅡ와 기능점수 방식의 원가요소를 비교해 본 결과 데이터의 크기(DATA),제품의 복잡성(CPLX) 등의 요소가 기능점수의 원가요소와 관련성을 갖고 있는 것을 볼 수 있다. 그외 대다수의 원가요소가 기능점수방식의 요소와 관련성을 찾기가 힘들다. 이는 기능점수 방식의 특성을 원가요소가 그대로 나타내주고 있는 것으로 볼 수 있다. 프로젝트 초기 또는 사전 응용시스템 개발비용산정방식으로 사용하기가 곤란하고, 사용언어, 개발자의 기술, 개발환경, 4GL과 상용 컴포넌트를 이용하는 경우 등과 같은 시스템 개발방법과는 직접 관련이 없고, 일관된 척도로 시스템의 가치를 평가하는 특성을 가진 비용산정 방식임을 알 수 있다.

 

기능점수 방식에서는 개발비용산정에 반영할 요소로 기능증대요인만으로 부족한 점을 성능특성요소와 품질특성요소로 보완하고 있다. 성능특성과 품질특성의 영향도를 판정하여 기술적 복잡도를 산정하여 기능점수 계산에 포함하여 개발비용산정에 반영할 수 있도록 하고 있다. COCOMOⅡ의 제품지향 원가요소, 플랫폼지향 원가요소, 인력지향 원가요소, 프로젝트지향 원가요소 등에 부족한 요소가 품질특성과 성능특성에 많이 포함되어 반영되고 있다.

 

(1) 성능특성

– 데이터 통신

– 분산처리 여부

– 처리 속도

– 이용률

– 단위시간당 처리량

– 온라인 데이터 입력

– 온라인 데이터 갱신

– 처리의 복잡성

– 반응(reaction) 시간

– 회수(turnaround) 시간

– 응답(response)시간

 

(2) 품질특성

– 시험 용이성

– 이식성

– 재사용성

– 설치 용이성

– 작동 편의성

– 다중 설치성

– 효율성

– 신뢰성

– 융통성

– 무결성

– 상호 운용성

– 유지보수 용이성

 

6.2. 주요한 원가산정요소

 

6.2.1 소프트웨어 시스템 개발비용산정에서 주요 요소

응용시스템 개발비용 산정에 사용되는 원가요소들을 비교해 본 결과, 소프트웨어 개발비용산정방식들에서 공통적으로 동일하게 정의하고 있는 원가요소 또는 관련성 있는 원가요소로 정의하고 있는 것을 중심으로 주요요소로 정리해보고자 한다.

 

(1) 소프트웨어 제품지향 원가요소

1) 제품신뢰성과 복잡성

– 소프트웨어 제품의 신뢰성 요구 정도

– 데이터의 크기(테이블간의 논리적 구조의 복잡성)

– 소프트웨어 제품의 복잡성

– 라이프사이클 단계마다의 산출물 적합성

– 화면 입출력(사용자 인터페이스)의 복잡성

– 외부 루틴과의 인터페이스 복잡도

2) 소프트웨어 제품의 재사용성

– 재사용성 요구 정도

 

(2) 플랫폼지향 원가요소

1) 플랫폼 제약

– 실행시간 제약

– 주기억장치 제약

2) 개발 진행중 플랫폼 변경의 정도

 

(3) 인력지향 원가요소

1) 투입인력의 능력

– 시스템(업무) 분석가의 능력

– 프로그래머의 능력

– 프로젝트 기간중 투입인력의 계속성

– 팀의 결속력

2) 투입인력의 실무경험(유사프로젝트 참여경험)

– 유사 응용시스템 경험

– 개발언어와 도구 사용경험

– 플랫폼 사용경험

 

(4) 프로젝트지향 원가요소

1) 요구되는 개발일정계획

– 개발일정계획

2) 프로젝트추진인프라

– 소프트웨어 도구의 사용

– 복수의 개발장소(개발참여자들간의 의사소통)

– 프로세스 성숙도 수준

– 위험관리/ 위험해결성

주요한 산정요소에서 언급되지 않은 요소라 할지라도 개발비용산정에서 배제되는 원가요소로 여겨진다는 것은 아니다. 다만 주요 원가요소의 노력승수 값, 가중치 등을 적정히 결정하기 위해 판단기준에 해당하는 항목들을 집중적으로 조사하여 가능한 개관적 판단요소를 반영하여야 할 필요성이 있다는 점을 강조하는 것이다. 그 외의 요소들도 비용산정에 반영해야 함은 물론이다. 원가요소로 다루어지지 않은 요소라 할지라도, 해당 시스템개발비용 산정의 독특한 환경사항으로 반영하여야 할 요소가 있을 경우는 그 요소도 비용산정에 반영하여야 함은 물론이다.

 

6.2.2 상용소프트웨어(COTS)를 이용한 개발비용산정 주요요소

상용소프트웨어(COTS)을 이용한 시스템 개발비용산정에서 사용되는 원가요소들을 검토 비교해 본 결과, 개발비용산정방식들에서 공통적으로 정의하고 있는 원가요소 또는 관련성 있는 원가요소로 정의하고 있는 것을 중심으로 주요요소로 정리해보면 다음과 같다.

 

(1) 컴포넌트 제품의 성숙도

– 컴포넌트 제품의 상호 호환의 복잡성

– 컴포넌트 제품의 기술적 성능에 대한 제약성

– 컴포넌트 제품의 신뢰성

– 컴포넌트 제품의 편의성

– 컴포넌트 제품의 개방 호환의 표준에 대한 순응성

– 컴포넌트 제품의 성능

– 컴포넌트 제품의 이동성

(2) 컴포넌트 제작사의 지원도

– 컴포넌트 공급자의 제품 확장에 대한 의지

– 컴포넌트 제작사의 지원

– 컴포넌트 제작사의 교육과 설명서 제공

– 컴포넌트 제품 및 매뉴얼의 성숙도

– 컴포넌트 제공자의 성숙도와 제품에 대한 지원

– 컴포넌트 제공자의 교육

(3) 컴포넌트 제품 사용자의 성숙도

– 컴포넌트 제품에 대한 접착자의 경험

– 컴포넌트 접착자의 능력

– 컴포넌트 접착자의 통합에 대한 경험

– 컴포넌트 접착자의 지속성

– 컴포넌트 통합구조 및 위험부담 해결성

(4) 개발대상 시스템의 난이도

– 개발할 응용시스템의 이동성

– 개발할 응용시스템의 호환상의 복잡성

– 개발할 응용시스템에 대한 제한 및 하위시스템의 신뢰성

– 개발할 응용소프트웨어의 복잡성

 

6.2.3 웹 환경하 개발에서의 원가요소 변화

웹 환경하에서 인트라넷, 엑스트라넷 시스템 등의 개발이 활발하게 이루어지고 있음에 따라 그러한 시스템의 개발비용 산정의 사례가 증가하고 있다. 웹 기반 환경에서의 시스템 개발 제품들은 객체기반 시스템 구성, 멀티미디어의 활발한 활용, 많은 재사용 부품들 사용, 적은 외부 인터페이스, 단순함 등의 특성을 갖고 있다. 소프트웨어 엔지니어뿐만 아니라 그래픽 디자이너들의 활동이 두드러지기도 하고, 응용시스템 구성이 프레임웍 또는 템플리트 형태로 사용하는 비율이 높아짐에 따라 응용시스템 규모(size)산정이 어려워지고 있다. 이와 같은 추세로 인하여 COCOMOⅡ 설계단계 이전 모델의 원가요소를 기준으로 볼 때 계속 유지되는 요소, 정보기술 환경변화로 사라져야 하는 요소, 새롭게 추가되어야 하는 요소가 발생하고 있다.

 

(1) 유지되는 원가요소

1) 소프트웨어 신뢰성과 복잡성(RCPX : Product Reliability and

Complexity)

– RELY, DATA, CPLX, DOCU

2) 플랫폼 제약(PDIF : Platform Difficulty)

– TIME, STOR, PVOL

3) 투입인력의 능력(PERS : Personnel Capability)

– ACAP, PCAP, PCON

4) 투입인력의 경험(PREX : Personnel Experience)

– APEX, PLEX, LTEX

5) 프로젝트 추진인프라(FCIL : Facilities)

– TOOL, SITE

6) 일정계획(SCED : Required Development Schedule)

 

(2) 제외되는 원가요소

– 재사용성(RUSE : developed for reusability)

중요하지 않은 요소가 됨.

 

(3) 추가되는 원가요소

1) 팀 결속력(TEAM : Teamwork)

2) 프로세스 효율성(PEFF : Process Efficiency)

 

6.3 소프트웨어 개발비용의 적정성 유지방안

소프트웨어 개발비용산정 요소를 관리함으로써 전체 소프트웨어 시스템 구축비용의 결정에 융통성을 가져올 수 있다. 지금까지 살펴온 원가요소들의 특성 측면에서 소프트웨어의 개발비용을 적정하게 유지할 수 있는 방안을 정보화사업의 사례를 통하여 검토해보고자 한다.

 

6.3.1 소프트웨어 개발비용의 적정성 유지 고려요소

응용시스템 개발과 관련된 원가요소에 관한 앞에서의 검토결과 원가요소가 크게 네 가지 분류로 되는 것을 알 수 있었다. 각 분류에서 개발비용의 적정성을 유지할 수 있는 고려요소를 살펴본다.

 

(1) 소프트웨어 제품지향의 원가요소

개발되는 소프트웨어의 신뢰성을 높이기 위한 노력을 기울여야 한다. 기능과 성능이 입증된 개발도구의 사용이라던가, 사용자의 요구사항이 잘 반영된 상세설계서의 확보후 프로그램 개발/구현/테스트가 이루어 wu야 한다. 사용자의 변경요청의 가능성을 최소화하기 위해서라도 사용자의 요구사항이 충분히 반영된 상세설계서의 작성이 필수적인 것이다. 프로젝트 현장에서 준수되는 모습을 보기 어려운 사항이다. 현장에서는 개발 진행 중 사용자의 변경요청사항이 수시로 발생하는 현실이다.

데이터베이스의 크기/복잡도 개선방안으로는, 데이터베이스의 물리적설계, 논리적설계 단계의 철저한 수행이 필요하며, 최종 단계에서 튜닝작업까지 가능하면 좋을 것이다. DBA와 개발자들간의 의사소통이 활발하여 데이터베이스 관련 교육효과가 있어야 하고, 개발자들이 데이터베이스의 성능을 고려한 코드의 구현이 이루어져야 한다.

모듈화, 시스템 분석/설계기법의 적용, 개발 라이프사이클 각 단계마다의 적정한 산출물 문서화 등으로 시스템의 복잡성 완화, 재사용성 증대 등을 위한 노력을 기울이는 것이 바람직하다.

 

(2) 플랫폼 지향의 원가요소

시스템 자원의 성능상 사용률을 높여 부하를 가중시키는 요소는 배제하여야 한다. 모듈의 크기가 크거나, 인터페이스 빈도가 너무 많아서 운영시 프로세스의 크기, 실행시간, 메모리 사용률 등에 좋지 않은 영향을 미치는 것을 예방하여야 한다. 또, 프로젝트 초기에 시스템 구조 설계시 플랫폼 구성 내역에 대한 명확한 설계로 프로젝트 추진과정에서 구성 내역 중 일부가 변경되는 일이 발생하여서는 안된다.

 

(3) 투입인력 지향의 원가요소

인력은 프로젝트 추진에 있어서 주요요소이고, 개발비용에도 큰 영향을 미치는 요소이다. 투입되는 인력이 각 담당분야에 기술 보유한 적정한 인력투입, 유사 프로젝트에서의 경험을 보유한 인력을 선정하여 참여시켜야 한다. 신입사원, 초급기술자 중심의 개발팀 구성은 프로젝트 효율을 떨어뜨리는 주요한 원인중의 하나이다.

 

(4) 프로젝트추진 지향의 원가요소

프로젝트 관리의 주요 포인트마다 마일스톤이 설정된 추진일정계획의 수립과 준수관리활동으로 납기준수 및 일정지연의 예방이 필요하다. 개발장소의 단일화 노력, 개발팀원간의 의사소통 원활화를 위한 위원회 구성이나 검토회의의 실시, 프로젝트를 위한 소프트웨어 도구의 사용 등으로 프로젝트 관리 효율을 향상시킬 수 있어야 한다.

 

6.3.2 정보화사업 사례

사업명

구 분

가상 XX세계문화인프라 전자관광시장 구축

XX 지역문화관광산업 종합정보시스템

사이버 XX역사문화관 구축

시스템

주요내용/기능

– XX 세계문화엑스 포의 행사내용 및 소개를 DB화

– 전자관광시장

홈페이지

– 도정종합정보

홈페이지

– 역사문화유적지

동영상 보여주기

– 지역문화관광

산업 종합정보

시스템 DB구축

– 예약․주문

시스템 구축

– 종합민원실 민원

안내시스템

– XX텔 연계

– 사이버 백제역사

문화관 DB구축

– 관광지리정보

시스템

– 특산물 정보

시스템

소프트웨어

도구

– Adobe

– Premier

– Live Picture

– Adobe Photoshop

– Sound Edit

– icroStation

개발팀

(시스템공급자)

튼튼기술(주)

(주)튼튼전자

(주)튼튼정보

사업

기간

계획

99.2.5~10.4

99.3.25~11.30

99.4.18~9.18

실적

99.2.5~99.10.30

99.3.25~12.20

99.4.18~10.12

사업비

S/W

215,000,000원

223,800,000원

82,192,230원

H/W

220,000,000원

140,000,000원

44,902,000원

사용

플랫폼

UI

Web(Nescape)

Web

Web

DBMS

DBMS(Oracle)

ORACLE8

ORACLE

개발

도구

Power Builder

JAVA,CGI

지방자체단체의 지역정보화 사업의 사례를 간략히 검토해보고자 한다. 다섯 개 시의 지역정보화시스템으로 구축 목적과 시스템 내용/기능 등이 유사한 점이 많이 있는 시스템이다.

 

6.3.2.1 지역정보화사업 개요

사례로 든 지방자치단체의 지역정보화사업은 지역의 역사문화관광지 소개, 유적지 동영상 보여주기, 문화/관광정보 제공 등 유사한 내용/기능들이 포함되어 있는 시스템이 구축되었다. 구현하는 개발도구는 부분적으로 동일한 소프트웨어를 사용하기도 하고, 다양한 소프트웨어가 도입 사용되었음을 볼 수 있다. 개발팀(시스템 공급자)도 다섯 개 사업에 네 개 업체의 참여를 보이고 있다. DBMS는 동종의 제품을 사용하고 있다.

 

6.3.2.2 원가요소별 검토

동일/유사 업무내용과 기능을 구현하는 시스템이 지방자치단체별로 연속적으로 정보화사업으로 구현되어 유사프로젝트가 존재한다는 점과 개발비용의 적정성 유지방안에 착안하여 검토해보고자 한다.

 

(1) 개발단계별 적정한 산출물의 문서화

시스템개발 라이프사이클의 각 단계마다 산출물의 적정한 문서화가 이루어져야 할 것이다. 유사 프로젝트가 기간적으로 연속되어 발생할 경우, 각 단계마다의 산출물 문서화 작업시 템플리트로 활용함은 물론이고 내용까지도 수정 보완하여 작성할 수 있을 것이다. 프로젝트간의 공조 또는 동일한 시스템 공급자에 의해 수행되어야 가능할 것이다.

사업명

구 분

XX예술가상체험을 위한 멀티미디어 컨텐츠 개발

XX 가상박물관 및 관광정보센터 개발

시스템

주요내용/기능

– 문화재 및 유적지 원형보존을 위한 대화형 멀티미디어 보존 모형 개발

– 문화재, 유적지 DB

– 문화재 컨텐츠

– 문화예술유적컨텐츠

– 문화재 답사 컨텐츠

– 문화예술 관광정보

– 사이버 XX 문화 역사 박물관 홈페이지

– 사이버 문화 역사 박물관 가상 체험 서비스

– 관광 정보 서비스

– 지역 특산품 안내홍보 포탈 서비스

– 문화 역사 박물관 관련 사이트 정보 서비스

– 박물관 래방객을 위한 서비스제공

소프트웨어

도구

Inprise-Jbuilder

Namo Webeditor

Gallery Effect

Illustrator

Photoshop

Director, Flash

3D MAX, Cosmo World

Quick Time, Illustrator

PhotoShop

Live picture

image Server

개발팀

(시스템공급자)

(주)하하정보

(주)하하정보

사업

기간

계획

99.2.26~12.10

2000.3.1~10.31

실적

99.2.26~12.30

2000.3.1~10.31

사업비

S/W

440,000,500원

287,802,000원

H/W

110,000,500원

204,825,000원

사용

플랫폼

UI

Web(Explor)

Web

DBMS

ORDBMS

(Oracle)

Oracle

개발

도구

Application Builder

Delphi, JDK

XML 지원

 

(2) 소프트웨어의 재사용성 향상

유사 프로젝트의 존재는 소프트웨어 재사용 가능성이 높아질 수 있다. 시스템 내용/업무의 유사성과 동일 개발도구의 적용은 소프트웨어 재사용성 향상과 더불어 개발효율을 높일 수 있다.

 

(3) 응용시스템 경험도

유사프로젝트의 수행 경험이 있는 개발자의 투입으로 개발효율 향상효과를 볼 수 있다. 개발팀원이 유사 응용시스템 개발에 참여경험이 있을 때 개발비용이 감소될 수 있는 요인이 되는 것이다. 이는 시스템 공급자가 앞서의 프로젝트와 동일했을 때 가능할 것이다.

 

(4) 개발팀원의 능력과 팀웍

유사프로젝트 수행 경험이 있는 시스템 공급자(개발팀원)가 프로젝트에 참여할 경우, 소속 개발팀원(프로젝트관리자, 분석가, 프로그래머 등)의 경험으로 인한 능력향상과 팀원간의 결속도를 강화시킬 수 있는 가능성이 높다. 팀원간의 결속도 향상은 개발효율 향상으로 인한 개발비용도 절감효과도 볼 수 있을 것이다. 또 개발에 투입된 인력이 변동되지 않도록 하는 개발팀의 계속성 유지도 인력지향 원가요소 관리의 하나로 개발비용을 적정하게 유지하는데 한 몫을 담당할 수 있을 것이다.

 

(5) 개발언어와 도구의 사용경험

소프트웨어 개발언어와 도구의 사용경험이 있는 개발자의 확보는 개발효율 향상으로 적정한 개발비용을 유지할 수 있다. 유사프로젝트에 참여했던 개발팀의 확보는 개발언어와 도구의 사용경험도 동시에 확보할 수 있는 가능성이 높은 것이다. [표 6.8]의 사례에서 (주)하하정보가 참여한 두 사업에서 소프트웨어 도구(Illustrator, PhotoShop 등)는 동일한 도구를 사용한 부분이 보이고, 개발도구는 부분적으로 다른 도구를 사용한 것으로 보인다.

 

(6) 플랫폼 사용경험

프로젝트에 적용될 플랫폼의 사용경험이 있는 개발팀원의 확보도 개발효율 향상으로 적정한 개발비용을 유지할 수 있는 요소 중의 하나이다. 이것도 유사프로젝트에 참여했던 개발팀의 확보가 효과를 볼 수 있는 방법의 하나로 본다.

 

(7) 소프트웨어 도구의 사용

프로젝트 추진에 시스템 개발 관련 소프트웨어 도구 적용은 개발효율을 향상시키기 위한 필수적인 도구로 인식되고 있다. 이다. [표 6.8]의 사례에서도 다양한 소프트웨어 도구를 적용하고 있음을 볼 수 있다. 개발관련 소프트웨어 도구뿐만 아니라 CASE, 테스트 도구, 형상관리 도구, 일정관리 도구 등도 적용하여 프로젝트 관리에 효과를 볼 수 있다.

 

(8) 일정계획 관리

프로젝트 추진에서 일정계획의 준수는 어려운 현실이다. 실질적으로는 착수시점도 지연되는 사례가 있고, 완료시점도 지연되는 사례가 발생하는 경우가 있다. 사용자의 요구사항을 반영하면서 이루어지는 프로젝트 관리자의 일정계획/관리는 주요한 개발비용 결정요소의 하나이며, 프로젝트 관리자의 능력으로, 유사프로젝트 참여 경험이 있는 관리자는 일정관리에 개발일정 단축과 마일스톤의 결정 및 관리에 융통성 발휘와 효율을 향상시킬 수 있을 것이다.

 

6.3.3 소프트웨어 개발비용 적정성 유지방안 제안

사업의 구성내용이 동일 또는 유사한 프로젝트가 사업년도를 달리하여 정보화 사업으로 추진되는 경우가 발생할 수 있다. 이 경우 소프트웨어 개발비용을 결정하는 원가요소를 고려하여 개발효율을 향상시킴으로써 적정한 개발비용을 유지할 수 있도록 하는 것이 바람직할 것으로 생각된다. 유사 프로젝트 연속될 경우 소프트웨어의 품질은 유지하면서 응용시스템 개발비용을 절감할 수 있는 방안을 마련하여 적용할 수 있어야 할 것이다.

 

[표 6.8]의 사례에서와 같은 지역정보화사업이 다른 지방자치단체에서 연속될 경우 앞서의 프로젝트에 참여했던 시스템공급자와 개발팀원을 투입할 수 있도록 조치하여 다음과 같은 원가요소 측면의 효익을 볼 수 있도록 할 수 있다.

– 개발팀원의 응용시스템 경험도

– 개발언어와 도구 사용경험

– 플랫폼 사용경험

– 소프트웨어 도구의 사용

– 산출물의 적합성

– 소프트웨어의 재사용

– 개발팀원의 능력과 팀웍 등

유사프로젝트에 참여했던 경험이 있는 개발팀원, 유사 프로젝트에 적용했던 개발언어, 도구, 플랫폼, 산출물 등을 해당 프로젝트에 투입될 수 있게 함으로써, 원가요소 측면의 효과로 소프트웨어의 품질은 유지할 수 있으면서 전체 시스템 개발비용을 절감할 수 있을 것으로 본다. 동일내용 또는 유사프로젝트의 추진에 경험이 있는 개발인력들이 존재하는데도 전혀 경험이 없는 개발팀을 선정하여 프로젝트를 추진할 경우, 상대적으로 개발 효율이 떨어질 가능성을 점칠 수 있다.

 

 

제 7 장 토의 및 결론

본 연구는 현장에서의 정보시스템 원가계산 시행업무 수행 현실감각에 이론적 배경을 지원하는 방안의 하나로 수행되었다. 또 정보시스템 원가감리의 본격적인 연구에 앞선 과제로 원가계산에 필요로 하는 원가요소들과, 요소가 정보시스템 원가에 미치는 영향을 알아보고자 노력하였다.

전체적으로 정보시스템 원가계산의 구성으로 장비, 소프트웨어의 도입비용에 대한 사전 원가계산, 소프트웨어 구축비용, 시스템 운영(유지보수)비용의 원가계산에 대해 현장의 모습을 요약하여 설명하였다.

본문에서는 소프트웨어의 원가계산에 대하여 집중 검토하였다. 첫째, 소프트웨어 원가계산 프로세스에 대한 최신 이론과 모델에서 제시하고 있는 일반적인 모델에 대하여 검토하고 현실성을 알아보았다. 두 번째로는, Function Point 모델에서 제시하고 있는 원가요소들에 대해 검토하고 실현성을 제시해 보았다. 세 번째로는 최신 COCOMOⅡ 모델에서 제시하고 있는 원가요소들을 시스템 개발 라이프사이클에서 설계단계 이전에 적용할 수 있는 모델의 원가요소와, 시스템 구조 구현 단계 이후에 적용할 수 있는 원가요소 중심으로 집중적으로 검토하였다.

 

여기에서는 원가요소를 소프트웨어 제품 지향의 요소, 개발에 적용된 플랫폼 지향의 요소, 개발에 투입되는 시스템 분석가와 프로그래머 등의 인력지향의 원가요소, 그리고 프로젝트 추진기반 지향의 요소로 분류하고 각 요소마다 적정한 개발비용을 유지하는 방안을 도출하여 보았다. 동일한 시스템 구성내용 또는 유사프로젝트가 존재할 경우 해당 프로젝트를 참조하고, 수행 경험을 가진 개발팀의 확보 등으로 소프트웨어의 신뢰성과 개발효율을 높이고, 나아가서는 개발비용의 적정한 유지를 할 수 있을 것으로 보았다.

또한 소프트웨어 개발비용 산정 모델들에서 제시하고 있는 각종 원가요소들을 비교를 통해 관련성 분석을 시도하고, 주요한 원가요소를 도출하고자 시도하였다. 주요한 원가요소로 선정된 요소들을 프로젝트 추진/관리에서 주요관리항목으로 지정하고 비용이 상승되지 않도록 관리하여야 할 것이다.

 

이론적 배경을 지원하는 연구라서 현실성을 고려하고 검토해 보지 못한 점이 본 연구의 한계점으로 볼 수 있다. Function Point 모델은 우리 시장에서도 부분적으로 적용되고 있는 것으로 알려져 있다. 향후 Function Point 모델과 COCOMOⅡ 모델을 현장 시스템 개발비용 산정에 적용하여 원가산정결과를 실제 투입된 사업비와 비교하여, 정확성 내지 적정성을 검토해 보는 연구가 필요할 것으로 생각된다. 정보시스템 원가계산 현장에 대한 실증적 연구가 국내 소프트웨어 개발비용 산정 업계의 발전을 위해 도움이 될 것임은 명약관화한 사실이라고 말할 수 있다. 정보시스템 성과감리와 정보시스템 원가감리의 서막을 열기 위해, 소프트웨어 개발비용 산정에 관한 연구는 계속되고 투자가 확대되고 활성화되어야 할 것이다.

 

과학적이고도 적정한 사업비의 계산 및 지급은 시스템 공급자들의 사업성과와 관련될 뿐만 아니라 우리나라에서 생산되는 소프트웨어의 품질을 향상시킬 수 있는 첩경이기 때문이다.

출처 : http://blog.daum.net/siniperka/16904508

Leave a Reply

Your email address will not be published. Required fields are marked *