[요구사항 공학] 요구사항 분석하기 (4)(마지막) - 요구사항에 근거한 평가

 요구사항에 근거한 평가

 

소프트웨어 프로젝트 팀들은 프로젝트 수행에 요구되는 노력, 시간 비용을 산정해야 한다. 이런 평가 작업은 특별한 해법도 존재하지 않는 골치아픈 과정이다. 여기서는 몇 가지 평가 접근 방법과 요구사항에 기초한 평가를 생성하는 세가지 기법을 소개한다.

 

 

평가의 몇 가지 기본원칙

평가란 주어진 정보와 지식, 특정 시점에서의 조건들을 바탕으로 하는 미래에 대한 예측이다. 예측이기 때문에 불확실성을 항상 포함한다. 프로젝트 관계자들은 프로젝트 초기에 정확한 평가를 요구하지만 이것은 불가능하다.

 

 

[그림1 - 요구사항 평가]

그림에서 보는 것과 같이 프로젝트를 완료할 확율은 5개월 이내는 10%이고, 10개월 이내는 30%이며 15개월에서야 비로소 80%이상이된다. 프로젝트 관리자에서 10개월이면 됩니다. 이렇게 콕 찍어서 말하자 마라. 만약 정확히 언제쯤 제품을 출시할 수 있을지 평가하여야 한다면 평가의 불확실성에 대한 완충치를 포함시켜야 한다.

 

평가 접근 방법

상향식 (Bottom-up) : 각각 개별 요소의 요구사항, 임무, 작업내역 상의 납품물 또는 클래스, 프로그램 모듈, 테스트 케이스와 같은 항목의 개수를 정하고 이것을 모아서 평가한다. 이때 MS Project같은 툴을 이용해서 많이 했다.

 

하향식 (Top-down) : 제품이나 프로젝트에 대한 전반적인 설명으로 부터 시작한다. 평가자는 유사 프로젝트 경험에 기초하여 전체 프로젝트를 수행함에 있어서 무엇이 필요한지 판단한다. 이 같은 전반적인 평가를  근간으로 하여 하부 컴포넌트 크기 각 개별 요소개발에 필요한 노력, 시간, 비용등을 평가하게 된다.

 

비용 모델 : 많은 상용 평가 도구들을 이용할 수 있다. 뭔가 복잡한 모양이다. 제품 마다 프로젝트로 부터 파생된 알고리즘을 이용한다. 팀을 두 배로 꾸린다고 해서 일정이 절반으로 줄어들진 않는다.

 

전문가 의견 : 유사 프로젝트를 진행해온 전문가들로 부터 평가를 받는것이다.

 

유추 : 기존 프로젝트와 신규 프로젝트를 비교해서 지난번 프로젝트와 크기가 비슷한가? 지난번과 확연히 다른 차이점이 있는가?

여러 가지를 판단하여 일정, 기간, 인력을 산정한다.

 

광대역 델파이 방식 : 한 그룹의 평가관들을 포함하는데 이들은 독립적으로 기초 평가를 하고, 그런 다음 모두의 지식을 수용하여 가능한 범위의 평가 결과를 얻기 위해 반복적으로 의견을 수렴을 진행한다. 여러명이 진행하므로 한명이 판단하는 것보다 위험요소를 제거할 수 있다. 그러나 시간이 많이 걸릴 수 있겠다.

 

평가가 목적이 아니다.

평가의 목적은 그에 상응하는 노력, 비용, 시간, 구성원을 결정하는 것이라고 설명한다. 하지만 때론 평가는 다른 의미를 갖기도 한다. 만일 제품 납품일자가 절대로 변경 불가능하도록 제한된 경우, 이에 대한 평가 요소는 고정된 일정 안에 요구되는 품질의 기능이 어느 정도 제공될 수 있느냐가 된다. 관리적으로 설정된 일정이나 마케팅 측면에서 설정된 납품 일정은 평가가 아니라는 것을 반드시 인식 시켜야 한다. 이것은 목표이다. 일정 크기와 기술 수준을 겸비한 팀만이 고정된 일정 내에 고품질의 기능을 만들어 낼 수 있다.