소프트웨어 개발에서 계획의 필요성 (개발 비용 산정 기법 COCOMO, 기능점수 FP)

개발을 하려면 계획을 세워라... 너무 당연한 말인것 같아서 좀 유치하긴 하다. 

그런데 왜 계획을 세워야 해? 라고 말해보면 오히려 또 당연한 말 밖에 못한다.

우리는 보통 계획을 세울 때 세부적으로, 체계적으로 계획을 세우지 못한다.

우리의 머리를 너무 믿은 나머지 나중에 후회하는 일이 생기기 마련이다...

우선 왜 계획을 세우는지 먼저 알아보자.

 

 

 

계획을 세우는 이유

만약 계획을 세우지 않았을 때 어떤 일이 일어나길래 굳이 계획을 세워야 할까.

나에게도 익숙한 모습이다. 방학숙제를 몰아서 하다가 예상치 못했던 돌발 위험 상황과 비용cost이 생겨서 정상적으로 마무리하지 못하는 경우가 있었다.

 

소프트웨어도 당연하다.

우리가 만드려는 소프트웨어가 다른사람이 이미 만들은 제품인지, 혹시 일어나면 곤란한 돌발 위험이 있는지, 비용은 얼마나 드는지 등 세부 계획을 세워놔야 그에 따른 일정을 맞추고 비용이나 자원을 알맞게 준비할 수 있다.

만약 이런 계획을 잘못 세우게 된다면 일정이 지연되고, 비용은 초과되어, 품질이 저하되므로 유지보수 비용이 미친듯이 증가할 것이다.

 

 

 

이런 상황을 방지하기 위해 우리는 우선 문제를 정의해야 한다.

우리가 만들고 싶은게 뭐지? 그럼 개발하고자 하는 영역에서 필요한 배경지식은 뭐지? 

이런 배경지식들을 본인이 직접 경험할 수 없다면 간접적인 경험으로 공부하거나 전문가를 초청해서 계획을 해야만 한다.
문제를 정의할 때는 배경지식이 많아야 가능하다.

 

 

이렇게 문제를 정의했다면 우리는 만든 제품이 판매되기 전에 먼저, 과연 이 제품이 잘 쓰일 수 있을까? 같은 경제적, 기술적인 타당성을 평가해야 한다.

뭐 아무것도 모르는 내가 평가해봤자 의미 없을테고, 예를 들면 경영자는 투자 효율성을 평가할 것이다. 분석가는 투자 대비 효과를 검토하여 시장 분석을 통해 시장성을 확인할 것이다.

이런 것들을 토대로 개발 여부를 판한다.

 

당연히 이런 경제적 타당성만 있는 것은 아니다. 기술적 타당성은 현재의 기술로 사용자가 원하는 기능을 구현할 수 있는지 검토하고, 법적 타당성은 개발용 소프트웨어와 도구의 사용(지적 소유권)이 법적으로 문제가 없는지 검토한다.

 

 

여기까지 했으면 개발 비용을 산정한다.

말만 들으면 쉬울것 같다. 왜냐? 다른 전자제품들은 자재 개수나 가격이 명확하기 때문에 쉽게 예측되는데 소프트웨어는  개발자의 능력에 따라 생산성이 달라지고, 다양한 개발 프로세스가 있기 때문에 개발 비용 산정 표준화에 어려움이 있다.

우선 어떤 요소들이 개발 비용에 영향을 주는지 알아보자.

프로그래머 자질과 소프트웨어 복잡도, 크기, 가용 시간, 신뢰도 수준(이게 무슨 말이냐면 개발 후 테스트하느라 그 기간 동안 의 비용은 그대로 더 들어간다는 뜻).... 등등 당연하긴 하지만 뭐가 많다.

 

 

그래서 비용을 산정하기 위한 기법이 몇 가지 있다.

그 중 하나로 하향식 산정 기법이 있다.

경험이 많은 전문가가 개발 비용을 산정하는 것이다.(신뢰성 높음) 이 경우는 짧은 시간에 개발비를 산정하거나 입찰해야 하는 경우 많이 사용한다. 하지만 수학적 방법보다 경험에만 의존할 경우 부정확할 수 있다는 단점이 있다.

이러한 단점을 보완한 방법으로 델파이 기법이 있다.

그냥 한번 더 의견의 일치를 물어보는 과정이 추가된 것이다.

 

 

다음으로 상향식 산정 기법들이다.

이 기법은 세부 작업 단위별로 비용을 산정한 후 전체 비용을 합산한다.
상향식 역시 하향식과 마찬가지로 경험에 의존할 경우 부정확할 수 있다

 

그 중 하나인 원시 코드 라인 수 LOC 기법을 소개하겠다.

이 기법은 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정 후 예측치를 구해 비용을 산정한다.

낙관적 : 한 모듈의 라인 수를 가장 적게 생각할 때의 예상 라인 수(가중치 1 부여)
비관적 : 한 모듈의 라인 수를 가장 많게 생각할 때의 예상 라인 수(가중치 4 부여)
기대치(중간치) : 한 모듈의 라인 수를 보통이라고 생각할 때의 예상 라인 수(가중치 1 부여)
추정 LOC : (낙관치+(4X중간치)+비관치)/6

 

다음으로 개발 단계별 노력 (Man/Month) effort per task 기법이다.

개발하려는 소프트웨어의 총 코드 라인 수를 예측하는 LOC를 보완한 기법으로

M/M을 소프트웨어 개발 생명주기의 각 단계에 적용하여 단계별로 산정한다. 이렇게 하면 코딩만 대상으로 산정하는 LOC보다 더 정확하다는 장점을 갖는다.

 

 

마지막으로 수학적 산정 기법이 있다.
이 기법은 상향식 비용 산정 기법으로, 다음 세 가지가 있다.

1. COCOMO

SW 규모(LOC)를 예측한 후 SW 종류에 따라 각 비용 산정 공식에 대입하여 비용 산정

2. Putnam

소프트웨어 생명주기의 각 단계에 소요되는 노력을 산정하기 위해 사용된다. 이 모델은 소프트웨어 개발과 유지보수에 필요한 노력의 분포를 가정하고, 프로젝트 특성을 고려하여 노력을 산정한다.

3. 기능 점수(FP)

기능 점수를 구한 후 이를 이용해 비용

 

 

 

우선 COCOMO 기법 먼저 알아보자.

코드의 라인 수를 추정하고 (LOC) 준비된 식에 대입해서 개발비M/M을 예측하여 산정하는 기법이다.

우선, 가중치를 반영한다.

LOC를 예상하고 > 유형에 따라 가중치를 부여해서 > M/M 계산한다

그 다음, 보정 계수를 반영한다.

가중치에 반영된 M/M을 계산하고 > 노력 조정 수치를 반영해서 > P/M을 계산한다.

마지막으로, 총 개발 기간을 산정한다.

계산된 P/M 으로 > 동일 상수를 적용하여 > 총 개발 기간을 산정한다.

 

 

위의 가중치 반영에서 유형을 나눈다는 점에서 알 수 있듯이, COCOMO 모델은 3개의 유형이 있다.

1. 단순형 프로젝트

복잡도와 난이도가 비교적 높지 않은 업무용 소프트웨어로 , 중소 규모에서 50KDSI 이하의 크기를 갖는다.

2. 중간형 프로젝트

규모나 복잡도가 중간정도 되고 300KDSI 이하 크기를 갖는다. 주로 운영체제나 데이터베이스 관리 프로그램에 사용된다.

3. 내장형 프로젝트

자동화 기기, 전자 제품과 같은 하드웨어와 밀접하게 관련 있는 소프트웨어이다. 크기는 300KDSI 이상이다.

 

이 표는 개발 인건비의 초기 예측 값 산출 방법이다.

 

위의 차트를 통해 유형별 M/M 을 평가할 수 있다. 보다싶이 단순형이 노력치가 제일 낮고 내장형이 제일 높다.

 

보정계수를 반영하기 위해 노력 조정 수치 EAF: effort adjustment factor 라는 값을 사용한다.

보정에 사용되는 값으로, EAF는 필요한 각 항목의 값을 모두 곱하여 구한다.

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

 

가중치가 반영된 M/M으로 이렇게 노력 조정 수치 EAF를 계산하여 P/M을 구한다.

만일 개발하려는 소프트웨어의 KDSI가 60이고, 소프트웨어는 중간 형이며, 노력 조정 수치(EAF)가 2.04라면 노력(E)?
PM=3.0× (KDSI)1.12×EAF = 3.0× (60) 1.12×2.04 = 600.179

 

 

 

이제, 총 개발기간 산정을 해야한다.

그 전에 COCOMO 방식은 계획단계의 원시코드 라인수를 예측한다는 문제가 있었다.

여기서 우리는 COCOMOII 방식으로 단계별로 값을 예측하여 인건비를 예측하는 것으로 문제를 보완했다.

 

 

이제 단계별로 값을 예측하기 위해, 각 진행 정도에 따른 분류를 할 필요가 있다.

1단계 : 애플리케이션 합성 모델
UI 개수를 계산하고  > 객체 점수를 산출해서 > SW 규모 산정

2단계 : 초기 설계 모델
이 단계에서 예측 값을 구한다.

3단계 : 구조 설계 이후 모델
기능 점수를 바탕으로 한 LOC를 추정하여 소프트웨어 규모를 산정

 

 

 

 

 

기능 점수 FP

 

다음으로, 기능 점수 FP를 산정하는 방법에 대해 알아보자.

이 점수를 산정하는 근거는 기능의 수와 사용자 관점에서 소프트웨어의 기능 정량화를 토대로 산정한다.

여기서 기능의 수(입출력, DB table, 인터페이스, 조회 등)는 라인 수와 무관하게 기능이 많으면 규모도 크고 복잡도도 높다고 판단하기 때문에 포함했고, 기능 정량화는 개발 비용을 산정하기 위함이다. 

이렇게 산정한 기능 점수를 토대로 소프트웨어 기능의 크기를 측정한다. 즉, 소프트웨어의 기능이 얼마나 복잡한지를 상대적인 점수로 표현하는 것이다.

 

그래서 기능 점수는 어떤 용도로 사용되길래 필요할까?

위에서 잠깐 말한 대로 개발 시 비용 산정과 유지보수 비용, 필요한 자원을 산정하는 곳에 필요하다.

이걸로 소프트웨어의 규모와 요구사항 복잡도를 측정한다.

 

각 기능들은 위와 같이 분류할 수 있는데 

기능을 도출해서 평균 복잡도를 적용할 것인지, 유형별 복잡도를 계산할 것인지에 따라 기획 단계에서 사용할지 설계 단계 이후에 사용할지를 판단한다.

 

 

이렇게 기능 점수를 산정해봤는데 이러한 방법의 장점으로는

사용자의 요구 사항만으로 기능을 추출하여 측정하거나 객관적인 요구 사항만으로 측정할 수 있고, 모든 개발 단계에서 사용 가능하다. (그래서 이게 왜 장점이냐면 실제 구현방법, 또는 개발 방법이나 팀과 무관하기 때문)

 

하지만 장점만 있는 것은 아니다.

요구 사항으로부터 기능을 도출하려면 상당한 분석 능력이 필요하고, 이러한 방법을 잘 사용할 수 있는 기능 점수 전문가가 따로 필요하다. 그리고 사용자가 알 수 있는 기능으로 측정하기 때문에 내부 로직 위주의 SW 측정에는 부적합하다.

그래도 개발 규모를 예측하는 데에는 적합하다.

예를들어 천원짜리 소프트웨어를 만들었다고 하면 내부 논리 파일은 천원에 7.5를 곱하여 내부 논리 파일에 대한 가격을 측정할 수 있다.

이런식으로 우리가 만드는 소프트웨어가 얼마나 비용이 드는지 각 기능에 가중치들을 부여하여 대략적으로 측정할 수 있었다.  

 

간이 기능 점수법이란 것도 있는데, 그냥 정확하게 산정할 수 없기 때문에 프로젝트 초기 단계에서 평균 복잡도 가중치를 사용하여 소프트웨어 기능의 크기를 측정하겠다는 것이다.

이런 간이 기능 점수를 산정하는 데에 필요한 절차로는 다음과 같다.

이제 단계별로 차근차근 알아보자.

1. 측정 유형 결정하기

내가 프로그램을 새로 만들것인지, 업그레이드를 할 것인지 등의 유형을 결정한다.

더 정확하게는 (1)개발 프로젝트 기능 점수(개발 규모 측정) 를 매길 것인지, (2) 개선 프로젝트 기능 점수(변경 규모 측정), (3) 애플리케이션 기능 점수(응용 규모 측정)을 매길 것인지를 선택한다.

(1)은 프로젝트가 완료되어 최초로 설치했을 때의 기능 크기를 산정하여 이 프로젝트에서 사용자를 위해 제공된 모든 기능을 측정한다.

(2)는 사용 중인 소프트웨어에 변경이 발생했을 때 변경된 부분의 기능을 측정하여 완료된 프로젝트에서 추가, 수정, 삭제된 부분만의 크기를 측정한다.

(3)는 현재 운용 중인 애플리케이션의 기능을 측정한다. 여기엔 위의 두 점수까지 다 포함된 것이다.

 

 

2. 측정 범위와 애플리케이션 경계 식별

범위 설정은 경계를 정확하게 구분짓는 단계이다. 만약 경계가 모호하다면 위 그림에서 내부 논리 파일 학사관리를 다른 두 외부 논리 파일에 포함시킬 수도 있다....

우선 어떤 요소들을 식별해야 하는지 생각해보자. 각 애플리케이션의 경계에 대해 생각해보자면, 이것은 금번 기능 점수를 계산하는 대상과 다른 애플리케이션이나 외부 사용자를 구분하는 경계이다.

하지만 경계를 식별할 때 주의해야 할 점이 있다.

꼭 사용자 관점에서 경계를 구분해야 한다. 클라/서버, 서버/비즈니스 같이 개발자 관점으로 구분하면 안된다...
또한 한번에 너무 포괄적인 경계를 갖지 말고 적당한 크기의 경계를 갖도록 해야 한다.

 

 

3. 데이터 기능 점수 계산

우리가 앱을 구분짓고 경계를 명확하게 했으면, 개발 대상의 논리 파일의(기능) 개수를 파악해서 확실하게 내 외부가 명확하게 구분될 것이다.

 

자꾸 내부, 외부 하는데 그래서 내부 논리 파일 Internal Logical File이 무엇일까

이것은 주로 데이터베이스에 존재하는 정보나 테이블을 말하며 사용자가 등록/삭제/수정/조회를 하기 위한 대상이다.
주로 앱에 존재하는 데이터를 논리적으로 모아놓은 것이다.

반대로 외부 연계 파일 External Interface File이란
측정 대상 앱에서는 참조만 하고 다른 앱에서 유지되는 파일을 말한다. 그러니까, 다른 프로젝트에서 생성했지만 이번 프로젝트에서 참조하는 데이터라는 말이다.

 

이런 외부와 내부 논리파일을 각각 가중치로 곱해서 더해서 데이터 기능 점수를 산출할 수 있다.

데이터 기능 점수 = {(ILF 개수×7.5) +EIF 개수 +5.4)}

 

 

4. 트랜잭션 기능 점수 계산

거창한건 아니고 트랜잭션 기능 측정은 앞서 말한 이러한 외부의 조회 횟수를 세는 것이다.

주로 시스템에서 외부 입력/출력/조회 같은 기능들의 개수를 갖고 각각의 가중치를 곱하여 구한다.

트랜잭션 기능의 예

트랜잭션 기능 점수 = {(EI개수 × 4.0) + (EO개수 × 5.2) + (EQ개수 × 3.9)}

여기서 외부 입력은 데이터베이스에 데이터를 등록하거나 수정, 삭제하는 것이 있다.
ex) 학생 정보 등록, 수정, 삭제

외부 출력은 계산하는 로직을 거쳐 데이터나 제어 정보를 사용자에게 보여주는 기능이다.
ex) 학생 학점 조회

외부 조회는 딱히 로직히 필요 없고 DB에 존재하는 데이터를 찾아 그대로 표시만 해주는 기능이다.
ex) 학생 주소 검색, 학생 정보 조회

 

 

5. 미조정 기능 점수 계산

보정 전 미조정 기능 점수는 앞에서 구한 데이터 기능 점수와 트랜잭션 기능 점수를 서로 더한 것이다.

단순히 기능적인 요구 사항에 대해서만 계산하고 여러 특성에 대한 고려는 하지 않는다.

미조정 기능 점수 계산 예시

 

 

7. 보정 후 기능 점수 계산

이제 보정 후 다음 4가지를 보정점수로 두고 계산한다. 

(1) 규모 보정 계수
규모에 따라 값을 보정하는 것으로, 예를들어 대규모인 경우에 복잡도가 증가하면 >> 생산성이 하락 >> 보정 계수를 높여서 보정한다.

(2) 애플리케이션 유형 보정 계수
소프트웨어 유형에 따라 복잡도가 달라 생산성도 달라지는 것을 보정한다.

애플리케이션 유형 보정 계수 예시

(3) 언어 보정 계수
언어에 따라서도 생산성이 달라지므로 보정 계수를 적용시킨다.

(4) 품질/ 특성 보정 계수
이하 생략 ㅋㅋ.. 대충 분산 처리, 성능, 신뢰성, 다중 사이트 등이 평가 요소로 있다.

 

 

8. 보정 후 개발 원가 계산

보정 후 개발 원가
= 보정 전 개발 원가 ×(규모 보정 계수 × 애플리케이션 보정 계수 × 언어 보정 계수 × 품질/특성 보정 계수)

보정 전 원가에 방금 설명한 4가지 요소들을 다 곱한것이 보정 후 개발 원가이다.

 

캡스톤할 때 보고서 기획 단계에서 다른 학년 분이 엄청 자세하게 정리하셨었는데... 지금 이 보정 후 최종 결과물을 보니 왜 그렇게 하셨었는지 이제 이해가 간다..