AI 기반 기능점수(FP) 측정·검증 도구는 전문가가 아닌 일반사용자 입장에서는 분명 매력적이지만, 실무·감사·분쟁 환경에서는 구조적인 한계가 명확하게 존재합니다. 아래에서 현실적인 문제점을 중심으로 몇가지를 정리해 보겠습니다.특히, 한국SW산업협회에서 홍보하고 제공하는 도구는 일반인들에게는 그럴싸하게 보이지만, 환각현상을 비롯한 상세 검증규칙 미비로 전문가에 의한 재검증을 통해서 잘못된 오류를 보완한 후 최종 규모르 활용되어 감사/심의/분쟁 등으로부터 자유로울 수 있습니다.
1. 요구사항 해석의 법적·규범적 한계
FP 측정은 단순한 요구사항에 대한 텍스트 분석이 아니라 업무를 포함한 규칙 기반 해석을 기반으로 책임 있는 판단이 요구되는 전문적인 지식과 경험에 기초한 결정 행위입니다.
[문제점]
AI는 IFPUG CPM 규칙에 대한 “경험을 통해 학습한 다양한 배경지식 이해”하지 못하고 패턴으로 흉내를 내는 수준임
“~할 수 있다”, “~을 고려한다”, “~을 지원한다” 같은 비기능/추상 표현을 기능요구사항(EI/EO/EQ)으로 오인식
법·지침에서는 “추정 금지, 명시된 요구사항만 인정” 이 원칙인데 AI는 요구사항을 의미적 추론으로 해석 해버림
[결론]
AI 단독 산출 FP는 감사·분쟁에서 증거능력 부족(지원도구의 역할) ==> 반드시 측정 전문가에 의한 검증이 요구됨
2. 단위프로세스(EP) 식별 오류
FP의 80% 오류는 EP 식별 단계에서 발생합니다.
AI는 행위어 기준 분해에 취약
하나의 EP(단위프로세스)를 화면 기준으로 쪼개거나 반대로 여러 EP(단위프로세스)를 하나로 측정
“조회조건 입력 + 조회 실행 + 결과 출력”을 EP(단위프로세스 2~3개로 과대 산정
AI는 행위어 중심으로 EP(단위프로세스)를 식별하는 한계로 1개의 EP를 2~3개의 EP로 과대 측정
AI는 “기능 흐름”보다 “문장 수”에 반응
3. DET / FTR 식별의 구조적 오류
[ DET 문제]
버튼, 라벨, 타이틀, 날짜 리터럴을 DET로 잘못 인식
중복 I/O 항목을 이중 DET 계산
“동작 트리거는 DET 1개” 규칙 미반영
[FTR 문제]
논리파일 경계(ILF/EIF) 판단 실패
이력·로그·집계 테이블을 무조건 ILF로 오판 → FTR 과대 계산
AI는 “데이터 의미”보다 “컬럼 나열”을 센다
4. 로그·이력 데이터 판단 오류
로그 = 무조건 데이터 기능(ILF)로 판단
실제 CPM 기준: 단순 기술 로그 → FP 제외
AI는 업무적 활용성 판단 불가
로그 FP는 AI 단독 판단 금물
5. 예산수립 단계에 FP규모와 사업대가의 불일치
AI는 요구사항 텍스트 기준으로만 판단
그러나 SW발주 단계 즉 예산 수립시점에는 요구사항이 추상적(개념적) 요구사항이 필연적임을 고려할때
AI 결과 기능점수와 사업수행에 필요한 사업예산간 불일치 문제 ==> 예산 과소 문제로 SW분쟁 유발
과업지시서, 제안요청서, 과업정의서 등 사업발주 시 명시된 요구사항이 추상적 개념이 아닌 요구사항 분석이 완료된 수준의 상세 요구사항이 전제되어야 근본적인 문제점이 해결된다.
6. 검증(Verification) 기능의 본질적 한계
AI는 “측정”은 흉내낼 수 있어도 검증자는 될 수 없습니다.
==> AI는 측정을 지원하거나 측정에 도움을 주는 도구이지뿐이며, 반드시 전문가에 의한 최종 검증을 통해 결과를 도출해야함
[검증에서 요구되는 것]
왜 EO인가?
왜 DET 7개인가?
왜 이 로그는 ILF가 아닌가?
==> FP 측정은 반드시 측정 근거 제시와 측정결과에 대한 책임문제 해결이 핵심
==> AI는 “설명 생성”은 가능하지만 책임지는 판단 주체가 아님
7. 감사·분쟁 대응 불가능
[현실]
감사원 / 과업심의 / 분쟁조정 등 객관적 근거와 규정 준수 문제에서 벗어나기 어려움
“AI도움으로 FP를 산출했음” → 감사, 분쟁, 심의 대응 불가
“사업대가 및 기능점수 전문가 FP측정 실무매뉴얼 및 SW사업대가 기준으로 판단” → Perfect
AI 결과는 참고자료일 뿐 결정 근거 불가
기능점수 측정 중에서 데이터 기능 측정 시에 마스터와 슬래이브 관계를 갖는 두개의 테이블이 첫케이스는 두개의 테이블이 동시에 생성 및 삭제되는 관계를 형성하고, 둘째케이스는 마스터 정보된 이후에 시간이 지나간 후 슬레이브 데이터 생성되는 관계이다.
두 케이스에서 논리파일과 RET가 어떻게 측정되는가?
1️⃣ 제3자 중립성 확보: 객관적 판단 기준
발주자·수행자 이해관계로부터 독립
요구사항·범위·대가에 대한 중립적 수치 제공
주관적 판단·관행 배제
🔹 “누구 편도 아닌, 기준의 편”
2️⃣ 사업 규모·대가의 정합성 검증
산정 FP의 규칙 준수 여부 검증
FP ↔ 사업비 ↔ 인력 투입 간 논리 검증
과대·과소 산정 식별
🔹 수치의 크기가 아니라 논리의 일관성을 본다
3️⃣ 발주·계약 문서의 측정 가능성 확보
RFP·과업지시서 요구사항 측정 가능성 진단
모호·중복·비기능 요구의 FP 오남용 방지
FP 산정이 가능한 구조로 요구사항 정제
🔹 측정 가능한 요구사항이 좋은 발주의 출발점
4️⃣ 변경·추가 요구에 대한 증분 분석
변경 전·후 FP 비교 분석
변경 사유·영향·대가의 정량적 설명
발주자·수행자 협의의 기준점 제공
🔹 “늘었다/줄었다”가 아니라 “얼마나”
5️⃣ 준공·검증·감사의 전문 증빙
계약 FP 대비 구현 기능 검증
감사원·내부 감사 대응용 근거자료
형식적 검토가 아닌 기능 실체 중심 검증
🔹 문서가 아닌 기능으로 검증
6️⃣ 분쟁·감정·조정에서의 전문 감정 역할
소송·중재·조정에서 감정 기준 제시
이해당사자 주장 검증 및 사실관계 정리
국제표준(ISO/IEC 20926) 기반 감정
🔹 말싸움이 아닌 표준 싸움
7️⃣ 조직·시장 관점: 측정 문화 확산과 표준 정착
발주기관·수행업체 대상 교육·내재화 지원
측정 오류·편차 감소
공공 SW 시장의 신뢰도 제고
🔹 컨설턴트의 가치는 숫자가 아니라 질서
🔎 측정 컨설턴트 관점 한 문장 요약
소프트웨어 측정 컨설턴트가 기능점수를 활용하는 목적은‘이해관계의 충돌을 표준으로 중재하고, 분쟁을 데이터로 해결하기 위함’이다.
1️⃣ 수주 전략 관점: 합리적인 제안가 산정
요구사항 기반 개발 규모 정량화
FP × 단가 기반 원가·마진 계산
저가수주(덤핑)·과대수주 리스크 관리
🔹 “이 가격으로 수행 가능한가?”를 사전에 판단
2️⃣ 제안서 경쟁력 확보: 논리적 설득 수단
가격 산정 근거를 표준(ISO) 기반으로 제시
발주기관 질의·평가 대응 용이
경쟁사 대비 합리성·투명성 어필
🔹 “비싸서가 아니라, 근거가 있어서 이 가격”
3️⃣ 계약 리스크 관리: 범위(Scope) 방어 수단
계약 시점의 기능 범위 명확화
‘무상 요구’, ‘당연 업무’ 주장에 대한 대응 근거
계약서·과업지시서에 FP 연계 시 분쟁 예방
🔹 말이 아닌 수치로 범위를 고정
4️⃣ 변경·추가 요구 대응: 증분 대가 산정 기준
요구사항 변경 시 증분 FP 산정
추가 인력·기간·비용 산정의 객관성 확보
발주자 협상 시 유리한 기준점
🔹 “해줄 수는 있지만, 추가입니다”
5️⃣ 수행 관리 관점: 내부 생산성·진척 관리
FP 기준 생산성(인월/FP) 관리
투입 인력·일정·리스크 조기 통제
프로젝트 간 성과 비교 가능
🔹 감이 아닌 데이터 기반 관리
6️⃣ 준공·검수·정산 단계: 대가 확보 수단
계약 FP 대비 구현 기능 이행 증빙
감액·삭감 주장에 대한 방어 논리
준공 지연·감액 분쟁 최소화
🔹 “개발은 끝났고, 근거도 있습니다”
7️⃣ 분쟁·감정 대응: 법적·전문적 방어 기준
사업비·범위 분쟁 시 중립적 기준
감정·조정·소송에서 활용 가능
내부 주장 아닌 국제표준(ISO/IEC 20926) 기반
🔹 최후의 순간에 가장 강한 무기
🔎 수행업체 관점 한 문장 요약
수행업체가 기능점수를 사용하는 목적은‘제값을 받고, 무리 없이 수행하며, 분쟁 없이 종료하기 위함’이다.
1️⃣ 사업 규모 산정의 객관성·정당성 확보
요구사항 기반으로 정량적 규모 산정
개발사 제안 규모의 과대·과소 산정 방지
인력 투입 M/M 산정의 근거 확보
🔹 “왜 이 사업이 이 금액인가?”에 대한 설명 가능한 수치
2️⃣ SW 사업비 산정의 합리적 근거 확보
FP × FP단가 방식으로 사업비 산정 근거 명확화
공공 SW사업에서
→ 국가계약법·SW사업대가산정 가이드 정합성 확보
감사·국회·상급기관 질의 대응 용이
🔹 “관행 가격”이 아닌 규정 기반 가격
3️⃣ 제안서 평가의 공정성 확보
업체별 제안 FP 비교로 물량 왜곡 여부 검증
가격평가와 기술평가 간 정합성 판단
‘저가·고가 제안’의 합리성 판단 가능
🔹 기술점수 ↔ 가격점수 간 불균형 방지
4️⃣ 계약변경·추가 요구 시 변경관리 기준
요구사항 추가·변경 시 증분 FP 산정
추가 사업비·기간 조정의 객관적 기준
“당연히 해줘야 하는 것” vs “추가 비용 대상” 구분
🔹 분쟁의 시작점인 범위(Scope) 모호성 제거
5️⃣ 사업 수행 결과물의 검증 수단
계약 FP 대비 실제 구현 기능 검증
누락·중복·미구현 기능 식별
형식적 준공이 아닌 실질적 성과 검증
🔹 “개발 완료”의 판단 기준을 문서가 아닌 기능 기준으로 전환
6️⃣ 분쟁·감사·법적 대응을 위한 증빙 자료
개발 범위·대가 관련 분쟁 시 중립적 판단 기준
감사원·감사부서 요구에 대응 가능한 정량 자료
소송·조정·중재 시 전문 감정 근거
🔹 감정·관행이 아닌 표준(ISO) 기반 근거
7️⃣ 장기적으로는 SW 발주 역량 내재화
유사 사업 간 규모·비용 비교 가능
기관 내부 SW 자산 데이터 축적
발주 품질 향상 → 실패 사업 감소
🔹 “업체가 설계한 사업”이 아닌 발주기관이 통제하는 사업
🔎 한 문장으로 요약하면
"발주기관이 기능점수를 사용하는 목적은
SW 사업의 규모·비용·변경·검증·분쟁을 ‘객관적 수치’로 통제하기 위함이다."
기능점수 자동 측정 및 검증 도구는 2가지(요구사항을 이용한 기능점수 자동화 도구, 프로그램 소스를 이용한 기능점수 자동화 도구)를 보유하고 있습니다.
본 도구는 당사가 보유한 관련 특허를 기초로 개발되었습니다. 본 도구는 SW사업정보저장소 데이터 수집 및 검증 지원 용역에서 5년 이상 활용하여 도구에 대한 품질은 확보되었습니다.
1. 요구사항을 이용한 기능점수 자동화 도구
2. 프로그램 소스를 이용한 기능점수 자동화 도구
1) 회사 소개
2) 측정 전문 서비스를 위한 전문 도구 및 자격 보유
3) ITO 대가체계 구축 컨설팅 및 운영 경험 보유
AI 기반 기능점수(FP) 측정·검증 도구는 전문가가 아닌 일반사용자 입장에서는 분명 매력적이지만, 실무·감사·분쟁 환경에서는 구조적인 한계가 명확하게 존재합니다. 아래에서 현실적인 문제점을 중심으로 몇가지를 정리해 보겠습니다.
특히, 한국SW산업협회에서 홍보하고 제공하는 도구는 일반인들에게는 그럴싸하게 보이지만, 환각현상을 비롯한 상세 검증규칙 미비로 전문가에 의한 재검증을 통해서 잘못된 오류를 보완한 후 최종 규모르 활용되어 감사/심의/분쟁 등으로부터 자유로울 수 있습니다.
1. 요구사항 해석의 법적·규범적 한계
FP 측정은 단순한 요구사항에 대한 텍스트 분석이 아니라 업무를 포함한 규칙 기반 해석을 기반으로 책임 있는 판단이 요구되는 전문적인 지식과 경험에 기초한 결정 행위입니다.
[문제점]
AI는 IFPUG CPM 규칙에 대한 “경험을 통해 학습한 다양한 배경지식 이해”하지 못하고 패턴으로 흉내를 내는 수준임
“~할 수 있다”, “~을 고려한다”, “~을 지원한다” 같은 비기능/추상 표현을 기능요구사항(EI/EO/EQ)으로 오인식
법·지침에서는 “추정 금지, 명시된 요구사항만 인정” 이 원칙인데 AI는 요구사항을 의미적 추론으로 해석 해버림
[결론]
AI 단독 산출 FP는 감사·분쟁에서 증거능력 부족(지원도구의 역할) ==> 반드시 측정 전문가에 의한 검증이 요구됨
2. 단위프로세스(EP) 식별 오류
FP의 80% 오류는 EP 식별 단계에서 발생합니다.
[문제점]
AI는 행위어 기준 분해에 취약
하나의 EP(단위프로세스)를 화면 기준으로 쪼개거나 반대로 여러 EP(단위프로세스)를 하나로 측정
“조회조건 입력 + 조회 실행 + 결과 출력”을 EP(단위프로세스 2~3개로 과대 산정
AI는 행위어 중심으로 EP(단위프로세스)를 식별하는 한계로 1개의 EP를 2~3개의 EP로 과대 측정
[결론]
AI는 “기능 흐름”보다 “문장 수”에 반응
3. DET / FTR 식별의 구조적 오류
[ DET 문제]
버튼, 라벨, 타이틀, 날짜 리터럴을 DET로 잘못 인식
중복 I/O 항목을 이중 DET 계산
“동작 트리거는 DET 1개” 규칙 미반영
[FTR 문제]
논리파일 경계(ILF/EIF) 판단 실패
이력·로그·집계 테이블을 무조건 ILF로 오판 → FTR 과대 계산
[결론]
AI는 “데이터 의미”보다 “컬럼 나열”을 센다
4. 로그·이력 데이터 판단 오류
[문제점]
로그 = 무조건 데이터 기능(ILF)로 판단
실제 CPM 기준: 단순 기술 로그 → FP 제외
AI는 업무적 활용성 판단 불가
[결론]
로그 FP는 AI 단독 판단 금물
5. 예산수립 단계에 FP규모와 사업대가의 불일치
[문제점]
AI는 요구사항 텍스트 기준으로만 판단
그러나 SW발주 단계 즉 예산 수립시점에는 요구사항이 추상적(개념적) 요구사항이 필연적임을 고려할때
AI 결과 기능점수와 사업수행에 필요한 사업예산간 불일치 문제 ==> 예산 과소 문제로 SW분쟁 유발
[결론]
과업지시서, 제안요청서, 과업정의서 등 사업발주 시 명시된 요구사항이 추상적 개념이 아닌 요구사항 분석이 완료된 수준의 상세 요구사항이 전제되어야 근본적인 문제점이 해결된다.
6. 검증(Verification) 기능의 본질적 한계
AI는 “측정”은 흉내낼 수 있어도 검증자는 될 수 없습니다.
==> AI는 측정을 지원하거나 측정에 도움을 주는 도구이지뿐이며, 반드시 전문가에 의한 최종 검증을 통해 결과를 도출해야함
[검증에서 요구되는 것]
왜 EO인가?
왜 DET 7개인가?
왜 이 로그는 ILF가 아닌가?
==> FP 측정은 반드시 측정 근거 제시와 측정결과에 대한 책임문제 해결이 핵심
==> AI는 “설명 생성”은 가능하지만 책임지는 판단 주체가 아님
7. 감사·분쟁 대응 불가능
[현실]
감사원 / 과업심의 / 분쟁조정 등 객관적 근거와 규정 준수 문제에서 벗어나기 어려움
“AI도움으로 FP를 산출했음” → 감사, 분쟁, 심의 대응 불가
“사업대가 및 기능점수 전문가 FP측정 실무매뉴얼 및 SW사업대가 기준으로 판단” → Perfect
[결론]
AI 결과는 참고자료일 뿐 결정 근거 불가
기능점수 측정 중에서 데이터 기능 측정 시에 마스터와 슬래이브 관계를 갖는 두개의 테이블이 첫케이스는 두개의 테이블이 동시에 생성 및 삭제되는 관계를 형성하고, 둘째케이스는 마스터 정보된 이후에 시간이 지나간 후 슬레이브 데이터 생성되는 관계이다.
두 케이스에서 논리파일과 RET가 어떻게 측정되는가?
1️⃣ 제3자 중립성 확보: 객관적 판단 기준
발주자·수행자 이해관계로부터 독립
요구사항·범위·대가에 대한 중립적 수치 제공
주관적 판단·관행 배제
🔹 “누구 편도 아닌, 기준의 편”
2️⃣ 사업 규모·대가의 정합성 검증
산정 FP의 규칙 준수 여부 검증
FP ↔ 사업비 ↔ 인력 투입 간 논리 검증
과대·과소 산정 식별
🔹 수치의 크기가 아니라 논리의 일관성을 본다
3️⃣ 발주·계약 문서의 측정 가능성 확보
RFP·과업지시서 요구사항 측정 가능성 진단
모호·중복·비기능 요구의 FP 오남용 방지
FP 산정이 가능한 구조로 요구사항 정제
🔹 측정 가능한 요구사항이 좋은 발주의 출발점
4️⃣ 변경·추가 요구에 대한 증분 분석
변경 전·후 FP 비교 분석
변경 사유·영향·대가의 정량적 설명
발주자·수행자 협의의 기준점 제공
🔹 “늘었다/줄었다”가 아니라 “얼마나”
5️⃣ 준공·검증·감사의 전문 증빙
계약 FP 대비 구현 기능 검증
감사원·내부 감사 대응용 근거자료
형식적 검토가 아닌 기능 실체 중심 검증
🔹 문서가 아닌 기능으로 검증
6️⃣ 분쟁·감정·조정에서의 전문 감정 역할
소송·중재·조정에서 감정 기준 제시
이해당사자 주장 검증 및 사실관계 정리
국제표준(ISO/IEC 20926) 기반 감정
🔹 말싸움이 아닌 표준 싸움
7️⃣ 조직·시장 관점: 측정 문화 확산과 표준 정착
발주기관·수행업체 대상 교육·내재화 지원
측정 오류·편차 감소
공공 SW 시장의 신뢰도 제고
🔹 컨설턴트의 가치는 숫자가 아니라 질서
🔎 측정 컨설턴트 관점 한 문장 요약
소프트웨어 측정 컨설턴트가 기능점수를 활용하는 목적은
‘이해관계의 충돌을 표준으로 중재하고, 분쟁을 데이터로 해결하기 위함’이다.
1️⃣ 수주 전략 관점: 합리적인 제안가 산정
요구사항 기반 개발 규모 정량화
FP × 단가 기반 원가·마진 계산
저가수주(덤핑)·과대수주 리스크 관리
🔹 “이 가격으로 수행 가능한가?”를 사전에 판단
2️⃣ 제안서 경쟁력 확보: 논리적 설득 수단
가격 산정 근거를 표준(ISO) 기반으로 제시
발주기관 질의·평가 대응 용이
경쟁사 대비 합리성·투명성 어필
🔹 “비싸서가 아니라, 근거가 있어서 이 가격”
3️⃣ 계약 리스크 관리: 범위(Scope) 방어 수단
계약 시점의 기능 범위 명확화
‘무상 요구’, ‘당연 업무’ 주장에 대한 대응 근거
계약서·과업지시서에 FP 연계 시 분쟁 예방
🔹 말이 아닌 수치로 범위를 고정
4️⃣ 변경·추가 요구 대응: 증분 대가 산정 기준
요구사항 변경 시 증분 FP 산정
추가 인력·기간·비용 산정의 객관성 확보
발주자 협상 시 유리한 기준점
🔹 “해줄 수는 있지만, 추가입니다”
5️⃣ 수행 관리 관점: 내부 생산성·진척 관리
FP 기준 생산성(인월/FP) 관리
투입 인력·일정·리스크 조기 통제
프로젝트 간 성과 비교 가능
🔹 감이 아닌 데이터 기반 관리
6️⃣ 준공·검수·정산 단계: 대가 확보 수단
계약 FP 대비 구현 기능 이행 증빙
감액·삭감 주장에 대한 방어 논리
준공 지연·감액 분쟁 최소화
🔹 “개발은 끝났고, 근거도 있습니다”
7️⃣ 분쟁·감정 대응: 법적·전문적 방어 기준
사업비·범위 분쟁 시 중립적 기준
감정·조정·소송에서 활용 가능
내부 주장 아닌 국제표준(ISO/IEC 20926) 기반
🔹 최후의 순간에 가장 강한 무기
🔎 수행업체 관점 한 문장 요약
수행업체가 기능점수를 사용하는 목적은
‘제값을 받고, 무리 없이 수행하며, 분쟁 없이 종료하기 위함’이다.
1️⃣ 사업 규모 산정의 객관성·정당성 확보
요구사항 기반으로 정량적 규모 산정
개발사 제안 규모의 과대·과소 산정 방지
인력 투입 M/M 산정의 근거 확보
🔹 “왜 이 사업이 이 금액인가?”에 대한 설명 가능한 수치
2️⃣ SW 사업비 산정의 합리적 근거 확보
FP × FP단가 방식으로 사업비 산정 근거 명확화
공공 SW사업에서
→ 국가계약법·SW사업대가산정 가이드 정합성 확보
감사·국회·상급기관 질의 대응 용이
🔹 “관행 가격”이 아닌 규정 기반 가격
3️⃣ 제안서 평가의 공정성 확보
업체별 제안 FP 비교로 물량 왜곡 여부 검증
가격평가와 기술평가 간 정합성 판단
‘저가·고가 제안’의 합리성 판단 가능
🔹 기술점수 ↔ 가격점수 간 불균형 방지
4️⃣ 계약변경·추가 요구 시 변경관리 기준
요구사항 추가·변경 시 증분 FP 산정
추가 사업비·기간 조정의 객관적 기준
“당연히 해줘야 하는 것” vs “추가 비용 대상” 구분
🔹 분쟁의 시작점인 범위(Scope) 모호성 제거
5️⃣ 사업 수행 결과물의 검증 수단
계약 FP 대비 실제 구현 기능 검증
누락·중복·미구현 기능 식별
형식적 준공이 아닌 실질적 성과 검증
🔹 “개발 완료”의 판단 기준을 문서가 아닌 기능 기준으로 전환
6️⃣ 분쟁·감사·법적 대응을 위한 증빙 자료
개발 범위·대가 관련 분쟁 시 중립적 판단 기준
감사원·감사부서 요구에 대응 가능한 정량 자료
소송·조정·중재 시 전문 감정 근거
🔹 감정·관행이 아닌 표준(ISO) 기반 근거
7️⃣ 장기적으로는 SW 발주 역량 내재화
유사 사업 간 규모·비용 비교 가능
기관 내부 SW 자산 데이터 축적
발주 품질 향상 → 실패 사업 감소
🔹 “업체가 설계한 사업”이 아닌 발주기관이 통제하는 사업
🔎 한 문장으로 요약하면
"발주기관이 기능점수를 사용하는 목적은
SW 사업의 규모·비용·변경·검증·분쟁을 ‘객관적 수치’로 통제하기 위함이다."
기능점수 자동 측정 및 검증 도구는 2가지(요구사항을 이용한 기능점수 자동화 도구, 프로그램 소스를 이용한 기능점수 자동화 도구)를 보유하고 있습니다.
본 도구는 당사가 보유한 관련 특허를 기초로 개발되었습니다. 본 도구는 SW사업정보저장소 데이터 수집 및 검증 지원 용역에서 5년 이상 활용하여 도구에 대한 품질은 확보되었습니다.
1. 요구사항을 이용한 기능점수 자동화 도구
2. 프로그램 소스를 이용한 기능점수 자동화 도구
1) 회사 소개
2) 측정 전문 서비스를 위한 전문 도구 및 자격 보유
3) ITO 대가체계 구축 컨설팅 및 운영 경험 보유
