4.소프트웨어 공학 계획 (COCOMO 방법)

7. 비용 산정 기법3 (수학적 산정 기법)

COCOMO 방법

• COnstructive COst MOdel

  COCOMO 방법의 개요

• 소프트웨어 개발 비용을 산정할 때 원시 코드의 크기, 즉 라인 수를 중심에 두는 방법
• 미국 TRW사의 보엠이 1981년에 저술한 《소프트웨어 공학 경제학》에서 이 방법을 제안
• 먼저 완성될 소프트웨어의 크기(라인 수LOC)를 추정하고 이를 준비된 식에 대입해 개발에 필요한 M/M을 예측

COCOMO 방법의 고려 사항

• 프로그램 유형에 따른 가중치를 두어야 함
• 개발하려는 소프트웨어를 제품, 컴퓨터, 개발자, 프로젝트의 4가지 특성에 따라 총 15가지로 분류한 후 인건비를 더 보정

가중치 반영하기

단순형 프로젝트

• 복잡도와 난이도가 비교적 높지 않은 업무용 소프트웨어가 이에 해당
• 중소 규모 정도이고, 크기는 50KDSI 이하

  중간형 프로젝트

• 일반 업무용 소프트웨어보다 복잡하고 규모가 더 큰 운영체제, 데이터베이스 관리 프로그램 등이 이에 해당
• 규모나 복잡도가 중간 정도이고, 크기는 300KDSI 이하

  내장형(임베디드형) 프로젝트

• 자동화 기기나 전자 제품과 같은 하드웨어와 밀접하게 관련 있는 내장형 소프트웨어가 이에 해당
• 크기는 300KDSI 이상

개발 인건비 초기 예측

• COCOMO 방법에서 제시하는 공식을 사용하면 개발 인건비의 초기 예측 값을 계산
• 규모가 같은 소프트웨어일 경우 기본형보다는 중간형에서, 중간형보다는 내장형에서 M/M이 더 많이 필요

보정 계수 반영하기

EAF: Effort Adjustment Factor

• 노력 조정 수치(EAF): 보정에 사용하는 값, 필요한 각 항목별 승수 값을 모두 곱한 값
• 15개의 세부 항목에 따른 보정 값을 모두 정해놓음

개발하려는 소프트웨어에 요구되는 신뢰도가 높고(1.15), 매우 복잡하며(1.30), 소프트웨어 공학 기술을 거의 사용하지 않고(1.24), 요구되는 개발 일정이 매우 촉박하고(1.10), 다른 요소들은 보통(1.00)일 경우 노력 조정 수치는 다음과 같다.

노력 조정 수치(EAF) =

1.15×1.30×1.24×1.10 = 2.04

노력 P/M

만일 개발하려는 소프트웨어의 KDSI가 60이고, 소프트웨어는 중간형이며, 노력 조정 수치(EAF)가 앞서 계산한 것처럼 2.04라면 노력(E: effort=P/M)은 다음과 같다.

PM = 3.0×(KDSI)1.12×EAF=3.0×(60)1.12×2.04 = 600.179

노력 조정수치가 반영된 노력 P/M을 구하는 공식

총 개발 기간 산정하기

• 보엠이 제시하는 총 개발 기간을 계산할 때는 개발할 소프트웨어 유형에 상관없이 모두 동일한 상수(2.5) 값을 곱함
• 개발 기간은 소프트웨어 유형과 상관없음 ![[Pasted image 20240318141518.png]] TDEV : Total DEVelpment time

앞서 사용한 예를 이용해 총 개발 기간을 구하면 다음과 같다. TDEV = 2.5×(PM)0.35 = 2.5×(600.179)0.35 = 23.461

COCOMO II 방법

애플리케이션 합성 모델

• 1단계에서는 입출력 화면 중심의 사용자 인터페이스 개수 등을 계산해 다음의 객체 점수를 산출 
• 개발 범위에 속한 객체(입출력 화면 등)를 찾음
• 객체가 제공하는 기능의 복잡도를 3가지(단순형, 보통형, 복잡형)로 분류
• 객체의 개수에 가중치(단순형, 보통형, 복잡형)를 부여해 결괏값을 산출

초기 설계 모델

• 2단계는 초기 설계 단계에서 예측값을 구함
• 초기 설계 단계쯤 되면 1단계보다는 시스템의 구조와 기능을 좀 더 상세히 알 수 있어 1단계보다 더욱 정확한 예측이 가능

구조 설계 이후 모델

• 3단계에서는 이미 기능 점수가 나왔기 때문에 노력을 추정하는게 어렵지 않음
• 기능 점수를 바탕으로 한 LOC를 추정해 소프트웨어 규모를 산정

애플리케이션 합성 모델 단계에서의 M/M 계산 샘플

7. 비용 산정 기법 3: 수학적 산정 기법

기능 점수 산정 방법의 개요

• 사용자 관점에서 소프트웨어의 기능을 정량화해 소프트웨어 개발 비용 산정에 활용
• 소프트웨어의 기능이 얼마나 복잡한가를 상대적인 점수로 표현
• 소프트웨어 유지보수 비용을 산정하는 데 사용
• 소프트웨어 개발 시 필요한 자원을 산정하는 데 사용

기능 점수 산정 방법의 용도

• 소프트웨어 개발 시 비용을 산정하는 데 사용
• 소프트웨어 유지보수 비용을 산정하는 데 사용
• 소프트웨어 개발 시 필요한 자원을 산정하는 데 사용

기능 점수 산정 방법의 특징

• 소프트웨어 규모를 측정하는 방법
• 기능적 요구사항이 중심이 되는 측정 방법
• 소프트웨어의 요구사항 복잡도를 측정
• 구현 관점(물리적 파일, 화면, 프로그램 수)이 아닌 사용자 관점의 요구 기능을 정량적으로 산정
• 측정의 일관성을 유지하기 위해 개발 기술, 개발 방법, 품질 수준 등은 고려하지 않음
• 소프트웨어 개발에 사용하는 언어와 무관
• 소프트웨어 개발 생명주기의 전체 단계에서 사용 가능

기능 점수 산정 방법

기능 점수 산정 방법

기능 점수 산정 방법의 구분

• 기능 점수의 기준이 되는 소프트웨어 기능은 크게 데이터 기능과 트랜잭션으로 구분

• SW사업 대가산정 가이드에서 제시하는 기능 점수 산정 방법 구분

기능 점수 산정 방법

기능 점수 산정 방법의 장점

• 사용자의 요구사항만으로 기능을 추출해 측정
• 객관적인 요구사항만으로 측정
• 모든 개발 단계에서 사용

기능 점수 산정 방법의 단점

• 높은 분석 능력 필요
• 기능 점수 전문가 필요
• 내부 로직 위주의 소프트웨어에는 다소 부적합
• 개발 공수보다 개발 규모 측정에 적합

간이 기능 점수법을 이용한 기능 점수 산정 방법

간이 기능 점수법

• 프로젝트 초기 단계에서 각 기능의 요소를 모르는 경우에 평균 복잡도 가중치를 사용해 소프트웨어 기능의 크기를 측정

평균 복잡도 가중치

• 과거에 수행한 소프트웨어의 기능 점수 산정 결과를 분석해 5가지 유형에 적용된 복잡도를 계산한 가중치의 평균값
• 사업 초기에는 기능 점수를 산정할 수 있을 만큼 자료가 충분하지 않으므로 평균 복잡도 가중치에 의존해 기능 점수를 산정
• 정상적인 기능 점수 산정 결과를 검증할 때도 평균 복잡도 가중치를 적용해 기능 점수를 산정

측정 유형 결정

개발 프로젝트 기능 점수(개발 규모 측정)

• 프로젝트가 완료되어 최초 설치했을 때의 기능 크기를 산정하는 것
• 프로젝트에서 사용자를 위해 제공된 모든 기능을 측정

  개선 프로젝트 기능 점수(변경 규모 측정)

• 사용 중인 소프트웨어에 변경이 발생했을 때 변경된 부분의 기능을 측정
• 완료된 프로젝트에서 추가, 수정, 삭제된 부분만 그 크기를 측정

  애플리케이션 기능 점수(응용 규모 측정)

• 애플리케이션 기능 점수는 현재 운용 중인 애플리케이션의 기능을 측정
• 개발 프로젝트 기능 점수에 개선 프로젝트 기능 점수까지 포함

측정 범위와 애플리케이션 경계 설정

측정 범위에 포함될 요소(서브시스템)의 식별

• 측정 범위: 기능 점수를 측정하고자 하는 대상

  애플리케이션 경계

• 애플리케이션 경계: 기능 점수를 계산하는 대상을 제외한 다른 애플리케이션이나 외부 사용자를 구분한 경계
• 경계를 지을 때 주의할 점은 사용자 관점에서 구분해야함(개발자 관점에서 구분해서는 안됨)
• 애플리케이션의 경계도 적당해야 함

데이터 기능 점수 계산

• 내부 논리 파일(ILF)의 개수와 외부 연계 파일(EIF)의 개수를 계산해 각각의 평균 복잡도에 따라 데이터 기능 점수가 결정

내부 논리 파일

• 사용자가 등록/수정/삭제/조회를 하기 위한 대상으로, 데이터베이스에 존재하는 데이터 모임(데이터베이스의 정보)
• 데이터베이스의 정보들은 기능 점수 측정 대상으로 애플리케이션 내부에서 파일로 유지

  외부 연계 파일

• 측정 대상 애플리케이션에서는 참조만 하고 다른 애플리케이션에서 유지되는 파일

데이터 기능 점수 계산

• 이번 프로젝트에서 생성해 관리하는 데이터는 내부 논리 파일(ILF)
• 이번 프로젝트에서 만들지 않고 다른 프로젝트에서 생성했으나 이번 프로젝트에서 참조하는 데이터는 외부 연계 파일(EIF)

• 데이터 기능 점수는 내부 논리 파일의 개수와 외부 연계 파일의 개수에 각각의 평균 복잡도(가중치)를 곱해 계산

트랜잭션 기능 점수 계산

• 기능 점수에서 트랜잭션 기능의 복잡도는 입력, 출력, 조회의 개수로 결정

외부 입력(EI)

• 데이터베이스에 데이터를 등록하거나 수정·삭제하는 것(학생정보 등록, 수정, 삭제)

  외부 출력(EO)

• 계산하는 로직을 거쳐 데이터나 제어 정보를 사용자에게 보여주는 기능(학생 학점 조회)

  외부 조회(EQ)

• 로직이 필요 없고 데이터베이스에 존재하는 데이터를 찾아 그대로 표시만 해주는 기능(학생 주소 검색, 학생정보 조회)

미조정 기능 점수 계산(UFP)

• 앞에서 구한 데이터 기능 점수와 트랜잭션 기능 점수를 합한 값
• 단순히 기능적인 요구사항에 대해서만 계산했지, 여러 가지 특성에 대한 고려를 하지 않음

보정 전 개발 원가 계산

• 미조정 기능 점수에 기능 점수당 단가를 곱해 계산

• 분석/설계와 구현/테스트를 구분해 별도의 사업으로 진행 시 복잡도 가중치와 가중치에 따른 단계별 단가를 적용

보정 계수

보정 계수의 필요성

• 규모와 유형도 다양하고, 연계 복잡성 수준, 성능요구 수준, 운영 환경 호환성, 보안성 수준이 프로젝트의 특성에 따라 다름
• 실제 개발 비용에 영향을 미치므로 이들에 대 해 보정 계수를 정하고 이를 반영해 보정한 후 개발 원가를 구해야 함

규모 보정 계수

• 기능 점수가 500FP 미만이면 규모 보정 계수 1.28을, 3,000FP 초과이면 1.153을 적용

애플리케이션 복잡도 보정 계수

• 사용자가 요구하는 소프트웨어가 복잡하다면 어려운 만큼의 보정 계수를 적용
• 애플리케이션의 복잡도는 연계 복잡성 수준, 성능요구 수준, 운영 환경 호환성, 보안성 수준으로 나뉨

보정 계수

애플리케이션 복잡도 보정 계수

• 연계 복잡성 수준
  • 연계 기관 수에 따른 보정 계수를 적용

• 성능요구 수준
  • 개발하려는 소프트웨어에 대해 사용자가 빠른 응답시간 또는 높은 처리율을 요구한다면 소프트웨어의 복잡도는 높아짐

애플리케이션 복잡도 보정 계수

• 운영 환경 호환성
  • 개발이 완료되어 설치할 때의 운영 환경(HW/SW)이 단순하지 않고 다음 표처럼 다양하다면 이를 보정 계수로 반영

• 보안성 수준
  • 보안에 대한 요구가 많을수록 복잡도는 높아지고 이를 다음 표처럼 보정 계수로 반영

보정 후 개발 원가 계산

• 5가지 보정 계수의 값을 구했다면 이 값을 적용해 보정한 후 개발 원가를 계산할 수 있음