규모·비용 추정의 가정

신청 함수가 20줄이니 전체 프로젝트도 하루면 완성된다는 판단은 정책 협의·저장 오류·검증을 놓칩니다. 규모는 만들 대상의 양이고 노력은 투입 작업량이며 기간은 시작부터 완료까지 흐른 시간입니다. 서로 관련되지만 같은 수치가 아닙니다.

무엇을 기준으로 셀까?

LOC는 코드 줄 수로 규모를 나타냅니다. 빈 줄·주석·생성 코드를 셀지, 언어와 표현 방식이 무엇인지에 따라 달라집니다. 같은 동작을 한 줄로 압축한다고 노력이 줄었다고 결론 내릴 수 없습니다.

기능점수(FP)는 사용자 관점의 입력·출력·조회·데이터 기능 등을 규칙에 따라 분류하고 규모를 평가합니다. 단순한 버튼 개수나 API 개수와 같지 않습니다. 기능 경계·분류·중복 판단과 적용한 계수 규칙을 남겨야 비교할 수 있습니다. 이 교재는 실제 프로젝트의 공식 FP 값을 산정했다고 주장하지 않습니다.

유사 프로젝트 추정은 실제 기록과 현재 범위의 차이를 비교합니다. 전문가·델파이 방식은 여러 판단을 독립적으로 모으고 차이의 이유를 조정하는 접근입니다. 여러 사람이 같은 근거 없는 수치를 반복한다고 정확도가 생기는 것은 아닙니다.

기능 경계부터 나누어 본다

기능 규모를 세려면 먼저 이번 소프트웨어가 관리하는 경계를 정합니다. 독서 모임 앱이 모임과 참가 관계를 관리하고 외부 회원 시스템의 자격 자료는 조회만 한다고 가정합니다. IFPUG 기능 규모 측정의 공식 표준 소개에서 산정 방법의 기준을 확인할 수 있습니다. 여기서는 사용자 기능을 입력·출력·조회·내부 데이터·외부 인터페이스 데이터로 나누는 연습부터 합니다.

여기서 ‘파일’은 물리 JSON 파일 개수가 아니라 사용자에게 의미 있는 논리적 자료를 가리킵니다. 같은 자료를 두 파일에 백업했다고 사용자 기능이 두 배가 되지는 않습니다. 웹과 명령줄이 같은 취소 처리를 호출하는 경우도 화면 수만큼 중복해서 셀 수 없습니다. 실제 산정에서는 기능 경계·기본 처리의 구별·자료 분류·복잡도 규칙을 더 확인해야 합니다.

독립 문제: 접점이 늘면 기능도 두 배일까?

웹 취소와 앱 취소가 같은 사용자 요구·처리·자료를 공유합니다. 이 둘 외에 신청, 단순 명단 조회, 참가율 계산 출력이 있고, 앱이 관리하는 논리 자료 묶음 하나와 외부에서 관리하는 참조 자료 묶음 하나가 있다고 가정합니다. 이 문제의 분류 가정에 따라 EI·EO·EQ·ILF·EIF의 개수를 구하고, 이것이 확정 FP나 비용은 아닌 이유를 쓰세요.

원자료의 기능점수 가중치·보정 계수와 COCOMO 계수표를 현재 공수에 그대로 적용하지 않습니다. 이 절은 논리 기능과 물리 코드의 차이, 단위·가정·민감도를 먼저 다룹니다. 경계에서 기능점수까지에서는 공개 SISP 3.0 적용 지침의 DET·RET·FTR 구간과 가중치를 확인해 여섯 기능의 UFP를 실제로 계산합니다. 현행 CPM 전체 적합성 확인과 비용 모형 보정은 별도입니다. 뒤의 가상 지수 계산도 실제 FP나 COCOMO 산정 결과가 아닙니다.

경험 모형의 용도와 한계

COCOMO와 같은 비용 모형은 코드 규모·프로젝트 특성 등을 이용해 노력을 추정합니다. 원형, 상세 모형, 후속 모형의 식과 계수가 다릅니다. Putnam 계열 접근도 규모·생산성과 인력·기간의 관계를 모형으로 다룹니다. 실제 관측에 맞게 보정하지 않은 식을 현재 프로젝트의 확정 일정으로 사용하지 않습니다.

아래는 지수형 모형의 민감도를 보는 가상 계산입니다. COCOMO의 공식 계수나 이 교재 제작 공수가 아닙니다. estimate-check.mjs로 실행합니다.

function toyEffort(size, coefficient, exponent) {
  return coefficient * size ** exponent;
}
const first = toyEffort(2, 3, 1.2);
const doubled = toyEffort(4, 3, 1.2);
console.log((doubled / first).toFixed(2));

출력 약 2.30은 이 가정에서 규모를 두 배로 늘려도 노력이 정확히 두 배가 되지 않음을 보여 줍니다. 계수를 외우기보다 입력 단위·자료 출처·적용 범위·민감도를 확인합니다. 모형이 그런 값을 냈다고 현실이 반드시 따르는 것은 아닙니다.

추정 기록의 최소 내용

추정에는 범위와 구간을 함께 남깁니다. 아직 확인하지 않은 작업에 정확한 완료 날짜나 완독 수치를 붙이지 않습니다. 낙관·보통·비관 값을 적을 때도 각 경우의 이유가 필요합니다. 인원 두 배가 기간 절반을 보장하지 않는 이유는 의존성과 소통 비용이 있기 때문입니다.

독립 문제: 줄 수가 늘었는데 품질은 좋아진 경우

ID 검증과 독립 테스트를 추가하니 코드 줄 수가 늘었습니다. 팀은 생산성이 나빠졌다고 판단합니다. 비교에서 빠진 요소와 더 적절한 확인 근거를 제시하세요.

규모·노력의 추정과 일정의 계산은 다른 작업입니다. 다음 문서에서 의존성이 기간을 어떻게 바꾸는지 확인합니다.