경계에서 기능점수까지
공개된 SISP 3.0 적용 지침에 따라 기본 처리와 논리 자료를 식별하고 DET·RET·FTR, 복잡도, 가중치, UFP를 직접 계산합니다.
같은 취소 기능을 웹과 모바일에서 제공한다고 기능 크기가 두 배가 되지는 않습니다. 기능점수는 구현 줄 수보다 사용자가 요구하는 논리 기능을 셉니다. 앞 절에서 분류한 여섯 기능을 이번에는 자료 항목과 참조 관계까지 적어 계산합니다.
사용할 규칙의 판본과 확인 범위
이 절의 복잡도 구간과 가중치는 브라질 정부가 공개한 SISP 「Roteiro de Métricas de Software」 3.0의 물리 PDF 30–40쪽, 특히 39쪽 표 3–5와 40쪽 표 6을 기준으로 합니다. 아래 한국어 설명과 모임 사례는 이 교재에서 구성했습니다. 이 지침은 CPM 4.3.1을 참조하고, 지침 자체가 전체 측정 매뉴얼을 대체하지 않는다고 밝힙니다.
정부 적용 지침의 계산 실습과 현행 IFPUG 표준 전체에 대한 적합성 확인을 구별합니다. 이 교재는 CPM 원문 전체나 유료 ISO 표준 본문을 확인하지 않았으며 인증 측정을 주장하지 않습니다. 다른 계약이나 측정 업무에 쓰려면 채택한 규칙의 판본과 적용 지침부터 합의해야 합니다. 특히 이 SISP 판본은 EO와 EQ의 복잡도 구간을 하나의 표로 제시합니다. 다른 방법의 표를 섞지 않습니다.
IFPUG 자체의 공개 iTip #1, Help Functionality, 2011년 1.0판도 논리적으로 같은 기능의 중복 판단과 EQ 사례를 설명합니다. 이 자료의 3–4쪽에서는 DET 3개 또는 4개, 참조 파일 1개인 도움말 조회를 낮은 복잡도의 EQ로 분류합니다. iTip 역시 전체 규칙집이 아닌 해석 사례입니다.
1. 측정 목적과 애플리케이션 경계를 적는다
이번 목적은 주어진 모임 기능 묶음의 조정 전 기능 크기를 비교하는 것입니다. 개발 계약 금액이나 사람 수를 산출하지 않습니다. 범위에는 다음 여섯 논리 기능만 포함합니다. 관리자 화면이나 외부 회원 시스템 전체가 구현되어 있다고 가정하지 않습니다.
경계 안에는 모임과 참가 내역을 유지하는 모임 애플리케이션이 있습니다. 경계 밖의 회원 시스템은 참가 자격 자료를 유지하고, 모임 애플리케이션은 그 자료를 읽기만 합니다. 웹·모바일 화면, 저장 라이브러리, 서버 배치가 나뉘어도 그 사실만으로 논리 경계를 추가하지 않습니다. 사용자가 별도 애플리케이션으로 인식하고 어떤 자료를 누가 유지하는지로 경계를 판단합니다.
기본 처리(elementary process)는 사용자에게 의미 있는 가장 작은 활동이며, 수행을 마치면 업무가 일관된 상태로 남아야 합니다. 등록 버튼 클릭, 내부 유효성 검사, 저장 함수 호출을 각각 세 기능으로 나누지 않습니다. 한 등록을 끝내기 위한 부분 작업일 수 있기 때문입니다. 웹과 모바일 취소가 같은 목적·자료·처리 논리를 사용한다면 하나의 기본 처리로 식별합니다. 화면 이름이 달라도 처리 논리가 달라지면 다시 비교해야 합니다.
| 종류 | 식별할 사용자 요구 | 사례에서의 판단 |
|---|---|---|
| ILF | 경계 안의 애플리케이션이 유지하는 사용자 인식 논리 자료 | 모임과 참가 내역 한 묶음 |
| EIF | 여기서는 참조하며 다른 애플리케이션이 유지하는 논리 자료 | 회원 시스템의 참가 자격 한 묶음 |
| EI | 입력 자료·제어 정보의 주목적이 ILF 유지나 동작 변경 | 참가 신청, 취소 각각 한 기본 처리 |
| EO | 단순 검색 외 계산·파생 자료 등의 처리를 포함하는 출력 | 참가율을 계산한 요약 |
| EQ | 계산·파생 자료·ILF 유지·동작 변경 없이 자료를 가져오는 조회 | 모임 제목 조회 |
EIF는 외부 HTTP 요청 횟수가 아닙니다. 같은 논리 파일을 두 번 호출해도 두 EIF가 되지 않습니다. 반대로 별도 사용자가 인식하는 논리 자료 두 묶음을 한 JSON 파일에 담았다고 한 파일로 합칠 수 있는 것도 아닙니다.
2. 데이터 기능에서 DET와 RET를 센다
DET(Data Element Type)는 사용자에게 인식되는, 중복되지 않는 자료 항목 종류입니다. RET(Record Element Type)는 그 논리 자료 안의 사용자 인식 자료 하위 집단입니다. 행 수나 회원 수를 세는 말이 아닙니다. SISP에서는 각각 DER, RLR라는 포르투갈어 약어를 사용합니다.
측정 사례의 요구를 아래처럼 명시합니다. 이는 앞 장의 작은 JavaScript 코어에 날짜·출처 기능이 이미 있다는 뜻이 아니라 계산을 위해 확장한 요구 명세입니다.
| 논리 자료 | 사용자 인식 하위 집단과 항목 | 중복 없는 DET | RET | 유지 주체 |
|---|---|---|---|---|
| 모임·참가 내역 | 모임: id, title, capacity, status / 선택적 참가 내역: memberId, joinedAt, cancelledAt, source | 8 | 2 | 모임 앱 |
| 참가 자격 | memberId, eligible, validUntil | 3 | 1 | 외부 회원 앱 |
여기서는 참가 내역을 모임에 속한 선택적이고 사용자에게 인식되는 하위 집단으로 요구했기 때문에 모임 자료에 RET 2개를 둡니다. 이를 독립적인 논리 자료로 인식하는 업무 요구라면 논리 파일 식별부터 바뀔 수 있습니다. 물리 테이블 수만 보고 RET를 정하지 않습니다. 관계를 표현하는 모임 id가 참가 내역에서 반복되더라도 같은 사용자 자료 항목을 이 논리 파일에서 다시 세지 않는다는 전제도 적습니다.
공유 자료에서는 우리 범위가 실제로 사용하는 항목만 셉니다. 모든 외부 회원 필드나 데이터베이스 내부 키를 자동으로 DET에 넣지 않습니다. 주소를 한 항목으로 쓰는지, 우편번호·시도 등을 독립 처리하는지도 사용자 요구에 따라 달라집니다.
3. 거래 기능에서 DET와 FTR을 센다
FTR(File Type Referenced)는 그 기본 처리가 읽거나 유지하는 ILF 또는 읽는 EIF의 수입니다. 같은 ILF를 읽고 쓴다면 FTR 하나입니다. SISP의 약어는 ALR입니다. 참조 파일 안의 모든 열이 경계 밖으로 나오는 것은 아니므로 FTR과 DET를 구별합니다.
이번 요구에서는 각 거래에 실행을 시작하는 하나의 제어 능력과 완료·오류 여부를 사용자에게 알리는 하나의 응답 능력이 있습니다. SISP 37쪽의 규칙에 따라 각각 DET 1개로 셉니다. 여러 버튼으로 같은 처리를 시작하거나 여러 오류 문구가 나와도 그 능력을 문구 수만큼 늘리지 않습니다. 화면 제목·고정 문구·페이지 넘김 같은 탐색 요소는 DET에 추가하지 않습니다.
| 기본 처리 | 경계를 오가는 DET의 근거 | DET | 참조 논리 파일 | FTR |
|---|---|---|---|---|
| 신청 EI | sessionId, memberId, 시작 제어 능력, 응답 능력 | 4 | 모임 자료 읽기·유지 1개 + 외부 참가 자격 읽기 1개 | 2 |
| 취소 EI | sessionId, memberId, 시작 제어 능력, 응답 능력 | 4 | 모임 자료 읽기·유지 1개 | 1 |
| 참가율 요약 EO | sessionId, registeredCount, capacity, ratio, 시작 제어 능력, 응답 능력 | 6 | 모임 자료 읽기 1개 | 1 |
| 제목 조회 EQ | sessionId, title, 시작 제어 능력, 응답 능력 | 4 | 모임 자료 읽기 1개 | 1 |
요약의 sessionId를 입력하고 다시 출력해도 같은 자료 항목은 한 번 셉니다. ratio = registeredCount / capacity를 계산하므로 여기서는 EO입니다. 제목 조회는 파생 자료를 만들거나 저장을 변경하지 않으므로 EQ입니다. 조회 버튼이라는 이름만으로 EQ가 되는 것은 아닙니다. 신청에서 내부적으로 읽은 eligible, validUntil은 사용자로부터 입력받거나 사용자에게 출력하지 않는다는 요구이므로 거래 DET에 자동 추가하지 않습니다.
4. 복잡도와 가중치를 적용한다
아래 구간은 SISP 3.0 물리 39쪽 표 3–5의 규칙 사실을 정리한 것입니다. 낮음·보통·높음은 기능점수의 분류이며, 구현이 쉽거나 어렵다는 주관적 평가를 뜻하지 않습니다.
| ILF·EIF의 RET | DET 1–19 | DET 20–50 | DET 51 이상 |
|---|---|---|---|
| 1 | 낮음 | 낮음 | 보통 |
| 2–5 | 낮음 | 보통 | 높음 |
| 6 이상 | 보통 | 높음 | 높음 |
| EI의 FTR | DET 1–4 | DET 5–15 | DET 16 이상 |
|---|---|---|---|
| 0–1 | 낮음 | 낮음 | 보통 |
| 2 | 낮음 | 보통 | 높음 |
| 3 이상 | 보통 | 높음 | 높음 |
| 이 지침의 EO·EQ FTR | DET 1–5 | DET 6–19 | DET 20 이상 |
|---|---|---|---|
| 0–1 | 낮음 | 낮음 | 보통 |
| 2–3 | 낮음 | 보통 | 높음 |
| 4 이상 | 보통 | 높음 | 높음 |
표의 EO·EQ 행은 지침에 함께 실려 있지만 EQ는 FTR이 최소 1개라는 표 5의 주석도 적용합니다. 이 절에서 실제 계산하는 EQ는 FTR 1개입니다. 공개 IFPUG 도움말 사례의 낮은 복잡도 판단과도 같은 조건입니다.
가중치는 SISP 3.0 물리 40쪽 표 6에 제시되어 있습니다.
| 종류 | 낮음 | 보통 | 높음 |
|---|---|---|---|
| ILF | 7 | 10 | 15 |
| EIF | 5 | 7 | 10 |
| EI | 3 | 4 | 6 |
| EO | 4 | 5 | 7 |
| EQ | 3 | 4 | 6 |
모임 ILF는 DET 8·RET 2이므로 낮음 7점입니다. 참가 자격 EIF는 DET 3·RET 1이므로 낮음 5점입니다. 신청 EI는 DET 4·FTR 2이므로 낮음 3점입니다. 신청이 두 파일을 참조하더라도 DET가 첫 구간이므로 보통으로 올리지 않습니다. 요약 EO는 DET 6이지만 FTR 1의 둘째 칸은 낮음이므로 4점입니다.
| 기능 | 종류 | 판단 수량 | 복잡도 | 가중치 |
|---|---|---|---|---|
| 모임·참가 내역 | ILF | DET 8, RET 2 | 낮음 | 7 |
| 참가 자격 | EIF | DET 3, RET 1 | 낮음 | 5 |
| 신청 | EI | DET 4, FTR 2 | 낮음 | 3 |
| 취소 | EI | DET 4, FTR 1 | 낮음 | 3 |
| 참가율 요약 | EO | DET 6, FTR 1 | 낮음 | 4 |
| 제목 조회 | EQ | DET 4, FTR 1 | 낮음 | 3 |
| 합계 | 25 |
UFP(Unadjusted Function Points)는 이 범위의 기능별 가중치를 더한 조정 전 크기입니다. 따라서 7 + 5 + 3 + 3 + 4 + 3 = 25 UFP입니다. 여섯 기능이 여섯 점이라는 뜻이 아닙니다. 일반 시스템 특성에 따른 역사적 보정, 전환 기능, 변경 프로젝트의 별도 산식, 계약 단가는 이번 합계에 넣지 않았습니다. 인일이나 완료 날짜로 바꾸려면 별도의 생산성 자료와 조건이 필요합니다.
5. 요구 변경에서 달라지는 항목을 추적한다
신청에 사용자 입력 phone 하나를 추가하고 모임 자료에도 보관한다고 합의했다고 합시다. 신청 EI는 DET 4에서 5가 되고 FTR은 2로 유지됩니다. EI 표에서 낮음 3점이 보통 4점으로 바뀝니다. 모임 ILF는 DET 8에서 9로 늘지만 같은 낮은 복잡도 구간입니다. 이 여섯 기능 묶음의 합계는 26 UFP가 됩니다. 필드 한 개를 더했다고 모든 기능의 점수가 오르는 것은 아닙니다.
외부 자격 자료를 모임 앱이 직접 유지하게 되면 EIF였던 자료의 경계 판단부터 바뀝니다. 같은 DET·RET 조건의 ILF 가중치 7과 EIF 가중치 5의 차이는 2입니다. 그러나 새 자격 관리 기본 처리가 필요한지 별도로 식별해야 하므로 이것만으로 변경 후 전체 크기를 27이라고 확정할 수는 없습니다.
웹과 모바일에서 같은 취소 기본 처리를 추가 노출하는 경우에는 취소 EI를 하나 더 넣지 않습니다. 새로운 처리 논리나 참조 자료를 도입했다면 중복 여부를 다시 판단합니다. 측정 기록에는 결과 숫자와 함께 이러한 판단 근거를 남깁니다.
6. 계산을 코드로 검산한다
저장소 루트에서 다음 명령을 실행합니다. 실행 위치 확인을 먼저 읽고 .mjs 파일에 대한 Node 실행이 되는지 확인하세요.
node docs/cs-textbooks/software-engineering-lab/function-points.mjs
node --test docs/cs-textbooks/software-engineering-lab/function-points.test.mjs첫 명령은 여섯 기능의 분류·가중치와 UFP: 25, 변경 후 26을 출력합니다. 검산 파일의 classifyFunction은 제공받은 종류와 DET·RET·FTR로 표를 적용하고, measureFunctions는 중복 id를 거부한 뒤 더합니다. EQ의 FTR 0, RET 0, 소수 DET 같은 입력도 거부합니다. 아래는 변경을 재현하는 부분입니다.
const changed = clubFunctions.map(fn =>
fn.id === 'register' ? { ...fn, det: 5 }
: fn.id === 'club-record' ? { ...fn, det: 9 }
: fn
);
console.log(measureFunctions(changed).UFP); // 26이 코드는 수량에 표를 적용하는 검산입니다. 문장을 읽고 애플리케이션 경계나 기본 처리의 유일성을 자동으로 찾아주지 않습니다. 잘못 식별한 기능을 입력하면 합계 계산이 정확해도 측정은 틀릴 수 있습니다. 테스트는 표의 경계값과 이 사례의 산술을 확인하며 전체 측정 규칙이나 현실의 요구 식별을 인증하지 않습니다.
독립 연습: 같은 한 필드라도 점수가 다를까?
위 기본 사례에서 제목 조회 EQ에 사용자 출력 startAt 한 항목만 추가합니다. 다른 요구는 그대로입니다. DET·FTR·복잡도와 여섯 기능 합계를 순서대로 계산하고 신청의 phone 추가와 비교하세요.
힌트
필드 수가 늘었는지와 복잡도 구간을 넘었는지를 각각 확인합니다.
해설
제목 조회의 DET는 4에서 5, FTR은 1입니다. EQ의 첫 구간에 머물러 낮음 3점이므로 합계는 25입니다. 신청의 DET 4에서 5 변경은 EI의 구간 경계를 넘고 FTR 2였으므로 합계 26이 되었습니다. 같은 한 항목 추가라도 기능 종류와 참조 수에 따라 결과가 달라집니다. startAt을 실제 보관하기로 추가 합의했다면 데이터 기능의 DET도 따로 확인해야 합니다.
다음 절부터의 품질 판단에서도 숫자의 정의·범위·판본을 함께 남깁니다. 크기, 구현 난이도, 학습 이해도는 서로 다른 측정 대상입니다.