계획을 세우는 이유
익숙한 모습이다.
당연하다면 당연하겠지만.. 방학숙제를 몰아서 한다면 예상치 못했던 돌발 위험 상황과 비용이 생겨서
정상적으로 마무리하지 못하는 경우가 많다.
소프트웨어도 당연하다.
우리가 만들려는 소프트웨어가 다른사람이 이미 만들은 제품인지, 혹시 일어나면 곤란한 위험이 있는지, 비용은 얼마나 드는지 등 세부 계획을 세워놔야 그에 따른 일정을 맞추고 비용이나 자원을 알맞게 준비할 수 있다.
만약 이런 계획을 잘못 세우게 된다면 일정이 지연되고, 비용은 초과되어, 품질이 저하되므로 유지보수 비용이 증가할 것이다.
이런 상황을 방지하기 위해 우리는 우선 문제를 정의해야 한다.
우리가 만들고 싶은게 뭐지? 그럼 개발하고자 하는 영역에서 필요한 배경지식은 뭐지?
문제를 정의했다면, 과연 이 제품이 잘 쓰일 수 있을까? 같은 경제적, 기술적인 타당성을 평가해야 한다.
여기까지 했으면 개발 비용을 산정한다.
말만 들으면 쉬울것 같지만 마냥 만만하진 않다.
소프트웨어는 개발자의 능력에 따라 생산성이 달라지고, 다양한 개발 프로세스가 있기 때문에 개발 비용 산정 표준화에 어려움이 있다.
(프로그래머 자질과 소프트웨어 복잡도, 크기, 가용 시간, 신뢰도 수준 등등...)
그래서 비용을 산정하기 위한 기법이 몇 가지 있다.
비용 산정 기법
기본적으로는 하향식, 상향식 산정 기법이 있다.
하향식 산정 기법은 간단하게
경험이 많은 전문가가 개발 비용을 산정하는 것이다.(신뢰성 높음)
이 경우는 짧은 시간에 개발비를 산정하거나 입찰해야 하는 경우 많이 사용한다.
하지만 수학적 방법보다 경험에만 의존할 경우 부정확할 수 있다는 단점이 있다.
이러한 단점을 보완한 방법으로 델파이 기법이 있다.
그냥 한번 더 의견의 일치를 물어보는 과정이 추가된 것이다.
다음으로 상향식 산정 기법들이다.
이 기법은 세부 작업 단위별로 비용을 산정한 후 전체 비용을 합산한다.
상향식 역시 하향식과 마찬가지로 경험에 의존할 경우 부정확할 수 있다
그 중 하나인 원시 코드 라인 수 LOC 기법이다.
이 기법은 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정 후 예측치를 구해 비용을 산정한다.
낙관적 : 한 모듈의 라인 수를 가장 적게 생각할 때의 예상 라인 수(가중치 1 부여)
비관적 : 한 모듈의 라인 수를 가장 많게 생각할 때의 예상 라인 수(가중치 4 부여)
기대치(중간치) : 한 모듈의 라인 수를 보통이라고 생각할 때의 예상 라인 수(가중치 1 부여)
추정 LOC : (낙관치+(4X중간치)+비관치)/6
다음으로 개발 단계별 노력 (Man/Month) 기법이다.
개발하려는 소프트웨어의 총 코드 라인 수를 예측하는 LOC를 보완한 기법으로
M/M을 소프트웨어 개발 생명주기의 각 단계에 적용하여 단계별로 산정한다.
이렇게 하면 코딩만 대상으로 산정하는 LOC보다 더 정확하다는 장점을 갖는다.
상향식 - 수학적 산정 기법
마지막으로 수학적 산정 기법 두 가지가 있다.
(실제로는 더 있긴 함)
1. COCOMO
SW 규모(LOC)를 예측한 후 SW 종류에 따라 각 비용 산정 공식에 대입하여 비용 산정
2. 기능 점수(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
이제, 총 개발기간 산정을 해야한다.
단계별로 값을 예측하기 위해, 각 진행 정도에 따른 분류를 할 필요가 있다.
1단계 : 애플리케이션 합성 모델
UI 개수를 계산하고 > 객체 점수를 산출해서 > SW 규모 산정
2단계 : 초기 설계 모델
이 단계에서 예측 값을 구한다.
3단계 : 구조 설계 이후 모델
기능 점수를 바탕으로 한 LOC를 추정하여 소프트웨어 규모를 산정
기능 점수 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. 미조정 기능 점수 계산
보정 전 미조정 기능 점수는 앞에서 구한 데이터 기능 점수와 트랜잭션 기능 점수를 서로 더한 것이다.
단순히 기능적인 요구 사항에 대해서만 계산하고 여러 특성에 대한 고려는 하지 않는다.
6. 보정 후 기능 점수 계산
이제 보정 후 다음 4가지를 보정점수로 두고 계산한다.
(1) 규모 보정 계수
규모에 따라 값을 보정하는 것으로, 예를들어 대규모인 경우에 복잡도가 증가하면 >> 생산성이 하락 >> 보정 계수를 높여서 보정한다.
(2) 애플리케이션 유형 보정 계수
소프트웨어 유형에 따라 복잡도가 달라 생산성도 달라지는 것을 보정한다.
(3) 언어 보정 계수
언어에 따라서도 생산성이 달라지므로 보정 계수를 적용시킨다.
(4) 품질/ 특성 보정 계수
분산 처리, 성능, 신뢰성, 다중 사이트 등이 평가 요소로 있다.
7. 보정 후 개발 원가 계산
보정 후 개발 원가
= 보정 전 개발 원가 ×(규모 보정 계수 × 애플리케이션 보정 계수 × 언어 보정 계수 × 품질/특성 보정 계수)
보정 전 원가에 방금 설명한 4가지 요소들을 다 곱한것이 보정 후 개발 원가이다.
