프로젝트 규모 추정 기법

프로젝트 규모 추정 기법

프로젝트 규모 추정은 프로젝트 관리자가 프로젝트 범위를 결정하고 그에 따라 리소스를 할당할 수 있도록 하기 때문에 소프트웨어 엔지니어링에서 중요한 활동이다.

 

다음은 소프트웨어 엔지니어링에 사용되는 일반적인 프로젝트 규모 추정 기법 들이다.

 

전문가의 판단

전문가 판단은 관련 분야의 전문가 그룹이 경험과 전문성을 바탕으로 프로젝트 규모를 추정하는 프로젝트 추정 기법이다. 

이 기법은 일반적으로 프로젝트에 대해 사용할 수 있는 정보가 제한적이거나 다른 추정 기법을 적용할 수 없을 때 사용된다. 전문가들은 추정치를 제공하기 위해 다양한 방법을 사용할 수 있는데, 예를 들어 유사한 프로젝트를 유추하거나 보다 정확한 추정치를 위해 프로젝트를 더 작은 구성요소로 세분화하는 것이다. 그런 다음 전문가가 제공한 추정치를 사용하여 보다 포괄적인 프로젝트 계획을 수립한다.

 

유사 추정

유사 추정은 현재 프로젝트와 이전에 완료된 프로젝트 간의 유사성을 기반으로 프로젝트 규모를 추정하는 프로젝트 추정 기법이다. 

이 기법은 유사한 프로젝트에 대해 과거 데이터를 사용할 수 있을 때 유용하며 과거 프로젝트의 실제 데이터를 사용하여 현재 프로젝트의 매개변수를 추정한다. 규모, 범위, 복잡성 및 기타 관련 요소 측면에서 현재 프로젝트를 과거 프로젝트와 비교하여 추정한다. 비교가 완료되면 과거 프로젝트의 실제 데이터를 사용하여 현재 프로젝트의 예상 매개변수를 계산한다. 이 기법은 빠르고 비용측면에서 효율적일 수 있으며 현재 프로젝트에 대한 합리적인 추정치를 제공할 수 있지만 현재 프로젝트가 비교에 사용된 과거 프로젝트와 유사하다는 가정에 의존한다.

 

상향식 추정

상향식 추정은 프로젝트를 더 작은 모듈이나 작업으로 나누고 각 작업을 개별적으로 추정하는 프로젝트 추정 기법입니다.

그런 다음 각 작업에 대한 견적을 집계하여 전체 프로젝트 견적에 추정한다. 이 기법을 사용하려면 프로젝트에 대한 자세한 이해가 필요하며 각 작업의 요구 사항, 리소스 및 제약 조건에 대한 철저한 분석이 필요하다. 각 작업에 대한 추정은 개별 작업에 대한 자세한 분석을 기반으로 하기 때문에 다른 추정 기법보다 더 정확할 수 있다. 그러나 이 기술은 시간이 많이 소요될 수 있으며 포괄적인 작업 목록 및 추정치를 생성하는 데 상당한 노력이 필요하다. 또한 다른 작업에 대한 종속성이 있는 작업을 추정하는 것이 어려울 수 있으며 한 작업에 대한 추정 오류가 전체 프로젝트 추정에 영향을 미칠 수 있다.

 

3점 추정

3점 추정은 프로젝트 규모를 추정하기 위해 낙관치, 비관치, 가장 가능성이 높(최빈치)은 세 가지 값을 사용하는 프로젝트 추정 기법이다.

낙관적 추정값은 모든 것이 계획대로 진행된다고 가정할 때 최상의 시나리오에서 추정 값이다. 비관적 추정치는 모든 것이 잘못된다고 가정하는 최악의 시나리오에서 추정값이다. 가능성이 가장 높은 추정치는 사용 가능한 정보를 기반으로 한 가장 현실적인 추정치다. 이러한 값은 프로그램 평가 및 검토 기술(PERT) 공식과 같은 공식을 사용하여 예상 프로젝트 규모를 계산하는 데 사용된다.

 

기능 점수

기능 점수는 제공하는 기능을 기반으로 프로젝트의 규모를 결정하는 소프트웨어 추정 기법이다. 

이 방법은 프로젝트 규모를 추정하기 위해 입력, 출력, 조회 및 파일 수와 같은 다양한 요소를 고려한다. 소프트웨어 개발 팀은 기능 점수를 사용하여 프로젝트의 복잡성을 더 잘 이해하고 이 정보를 사용하여 필요한 리소스를 계획하고 프로젝트를 완료하는 데 필요한 시간과 비용을 예측할 수 있다.

 

Use Case Points

Use Case Points는 소프트웨어가 지원해야 하는 사용 사례의 수를 기반으로 프로젝트의 규모를 결정하는 소프트웨어 추정 기법이다. 

이 방법은 각 유스 케이스의 복잡성, 유스 케이스에 관련된 행위자 수, 총 유스 케이스 수와 같은 다양한 요소를 고려하여 프로젝트 규모를 추정한다. 유스 케이스 포인트를 사용함으로써 소프트웨어 개발 팀은 소프트웨어 시스템의 요구 사항과 소프트웨어 설계 및 개발에 필요한 노력을 더 잘 이해할 수 있다. 이 기법은 필요한 리소스를 계획하고 프로젝트를 완료하는 데 필요한 시간과 비용을 추정하는 데 사용할 수 있다.

 

이러한 기법에는 각각 장단점이 있으며, 기법의 선택은 프로젝트의 복잡성, 가용 데이터, 팀의 전문성 등 다양한 요소에 따라 달라진다.

 

소프트웨어의 규모를 추정하는 것은 소프트웨어 프로젝트 관리의 필수적인 부분이다. 프로젝트 관리자가 프로젝트를 구축하는 데 필요한 노력과 시간을 추가로 예측하는 데 도움이 된다.

프로젝트 규모 추정에는 다양한 측정값이 사용되는데 그중 일부는 다음과 같다.

• 코드 라인(LOC)
• ER 다이어그램의 엔터티 수
• 상세 데이터 흐름도의 총 프로세스 수
• 기능 점수

1. LOC(Lines of Code)

이름에서 알 수 있듯이 LOC는 프로젝트에서 소스 코드의 총 줄 수를 계산한다. LOC의 단위는 다음과 같다.

• KLOC - 천 단위 줄의 코드
• NLOC - 주석 이외의 코드 수
• KDSI - 천 단위로 전달되는 소스 명령의 수

기존의 유사한 시스템과 비교하여 규모를 추정한다. 전문가들은 소프트웨어의 다양한 구성 요소에 필요한 규모를 예측한 다음 이를 추가하여 전체 규모를 구한다.

 

문제 정의만 분석하여 소프트웨어 응용 프로그램의 코드 줄(LOC) 수를 정확하게 예측하기는 어렵다. 최종 LOC 수는 전체 코드가 개발된 후에만 결정할 수 있다. 이는 프로젝트 초기에 만들어진 LOC 추정치가 부정확할 가능성이 높기 때문에 프로젝트 관리자가 거의 사용하지 않는다.

 

소프트웨어 애플리케이션의 코드 라인(LOC) 수는 이를 개발하는 데 필요한 노력을 항상 정확하게 측정하는 것은 아니다. 두 개의 개별 소스 파일이 비슷한 수의 줄을 가지고 있더라도 만드는 데 다른 수준의 노력이 필요할 수 있다. 이는 코드에서 사용되는 논리의 복잡성이 크게 다를 수 있기 때문이다. 더 복잡한 로직을 가진 파일은 라인 수가 비슷하더라도 간단한 로직을 가진 파일보다 만드는 데 더 오래 걸릴 수 있다.

 

프로그래밍 문제를 해결하는 데 걸리는 시간은 일반적으로 코드 라인(LOC)으로 측정되지 않는다. 그러나 작성된 코드 줄 수는 숙련된 프로그래머와 초보 프로그래머 간에 크게 다를 수 있다. 숙련된 프로그래머는 초보 프로그래머가 작성한 코드와 동일한 작업을 수행하는 보다 효율적이고 간결한 코드를 작성할 수 있다. 따라서 작성된 코드 줄 수는 프로그래밍 문제를 해결하는 데 걸리는 시간이나 생성된 코드의 품질을 나타내는 신뢰할 수 있는 지표가 아니다.

 

장점

• 일반적으로 COCOMO와 같은 많은 모델에서 사용된다.
• 개발자의 관점에 더 가까운 추정이 가능 하다. 
• 사용하기 쉽다.

단점

• 사용 중인 프로그래밍 언어에 따라 라인 수가 다르다.
• 표준이 존재하지 않는다.
• 프로젝트 초기에 규모를 추정하기 어렵다.

2. ER 다이어그램의 엔터티 수

ER(엔티티-관계) 모델은 프로젝트에서 정적 뷰를 제공하는데 이는 엔터티 및 해당 관계를 나타내는 방법이다. 

ER 모델의 엔터티 수는 프로젝트 규모를 추정하는 척도로 사용할 수 있다. 일반적으로 ER 모델의 엔터티 수는 프로젝트 규모에 비례한다. 엔터티가 많으면 더 많은 클래스 또는 Structures가 필요해서 더 많은 코딩이 필요할 수 있기 때문이다. 따라서 ER 모델의 엔터티 수는 프로젝트에 필요한 복잡성과 잠재적인 노력의 지표를 제공할 수 있다.

 

장점

• 프로젝트 초기 단계에서 규모 추정에 사용할 수 있다.
• 엔티티의 수는 사용되는 프로그래밍 언어와 독립적이다.

단점

• 표준이 없고, 일부 엔터티는 다른 엔터티보다 프로젝트의 규모와 복잡성에 더 큰 영향을 미칠 수 있다.
• FPA(Function Point Analysis)와 마찬가지로 비용 추정에서 덜 사용된다. LOC로 변환해야 한다.

3. 상세 데이터 흐름도의 총 프로세스 수

DFD(데이터 흐름 다이어그램)는 소프트웨어의 기능적 뷰를 나타내는 모델이다. 소프트웨어와 관련된 주요 프로세스 또는 기능과 이들 사이의 데이터 흐름을 보여준다. 

DFD의 함수 수는 소프트웨어의 규모를 예측하는 지표로 사용할 수 있다. 프로세스의 규모를 추정하기 위해 유사한 유형의 기존 프로세스를 검토하고 참조로 사용한다. 그런 다음 각 프로세스의 예상 규모를 합산하여 소프트웨어의 최종 예상 규모를 추정한다. 이 방법은 소프트웨어의 규모와 복잡성에 대한 일반적인 아이디어를 제공할 수 있으며 이를 개발하는 데 필요한 비용과 노력을 추정하는 기준으로 사용할 수 있다.

 

장점

• 프로그래밍 언어와는 독립적이다.
• 각 주요 프로세스는 더 작은 프로세스로 분해될 수 있다. 이 방법은 추정의 정확도를 높여준다.

단점

• 규모를 추정하기 위해 유사한 종류의 프로세스를 검토하려면 추가적인 시간과 노력이 필요하다.
• 모든 소프트웨어 프로젝트가 DFD 구성이 필요한 것은 아니다.

4. 기능점 분석

FPA(Function Point Analysis)는 소프트웨어 프로젝트의 규모와 복잡성을 측정하는 데 사용되는 방법이다. 

이 방법에는 소프트웨어에서 지원하는 다양한 유형의 기능을 식별하고 분류하는 작업을 수행한다. 각 기능에는 구현에 필요한 복잡성과 노력 수준에 따라 가중치가 할당된다. 모든 기능에 대한 가중치의 합은 소프트웨어의 크기와 복잡성을 나타내는 지표인 FPC(Function Point Count)를 계산하는 데 사용된다. 개발에 필요한 비용과 노력을 추정하고 다양한 소프트웨어 프로젝트의 크기와 복잡성을 비교하는 데 사용할 수 있다.

 

FPA(Function Point Analysis)와 관련된 일반적인 단계는 다음과 같다.

• 제안된 각 유형(외부 입력, 외부 출력, 외부 조회, 내부 논리 파일 및 외부 인터페이스 파일)의 기능 수 카운트한다.
• 각 기능 유형의 수에 기능 구현과 관련된 복잡성 정도를 기반으로 하는 해당 복잡성 요소를 곱하여 조정되지 않은 기능 점수(UFP)를 계산한다.
• 데이터 통신 요구 사항, 성능 요구 사항 및 운영 환경과 같은 소프트웨어 프로젝트의 복잡성에 영향을 미치는 다양한 요소의 영향을 평가하여 TDI(Total Degree of Influence)를 찾는다.
• TDI에서 평가된 다양한 요소의 상대적 영향을 평가하기 위해 일련의 기준을 적용하여 값 조정 계수(VAF)를 계산한다.
• UFP에 VAF를 곱하여 FPC(Function Point Count)를 찾는다. 

FPC는 소프트웨어 프로젝트의 규모와 복잡성을 측정하는 척도이며 프로젝트의 노력, 비용 및 기간을 추정하는 데 사용할 수 있다.

 

장점

• 프로젝트 계획 초기에 쉽게 사용할 수 있다.
• 프로그래밍 언어와는 독립적이다.
• 서로 다른 기술(데이터베이스, 언어 등)을 사용하더라도 서로 다른 프로젝트를 비교하는 데 사용할 수 있다.

단점

• 실시간 시스템과 임베디드 시스템에는 좋지 않다.
• COCOMO와 같은 많은 비용 추정 모델은 LOC를 사용하므로 FPC는 LOC로 변환해야 한다.