728x90
반응형
SMALL

기능점수 1탄, 2탄 에서는  기능점수(Function Point)의 정의 및 계산방식에 대해서 설명했다.
이번 장에서는 기능 점수를 계산하는 실제 사례를 설명하겠다.
우선 FTR , DET 에 대한 개념에 대해서 설명하고자 한다.

FTR  정보가 실제로 저장되는 논리테이블 개수 (즉 테이블 개수)
외부입력(EI)기능을 수행하는 동안에 참조하는 논리테이블 수
 Ex) 회원등록기능은 사용자마스터테이블에 정보가 저장되므로 FTR = 1
DET 사용자가 입력한 
   - 데이터 정보(Input 필드),  
   - 기능버튼(버튼,라디오,콤보박스), 
   - Message 개수 (에러메시지,확인메시지, 단 Notification Message는 아님)

회원가입화면의 기능점수
외부조회(EQ)


기능점수 측정유형

측정유형 설명
1 개발프로젝트
  기능점수 (DEP)
Development Function Point
개발완료시 프로젝트가 종료된 후 고객에게 최초 인도된 소트프웨어의 기능을 측정
2.개선프로젝트
  기능점수 (EFP)
Enhancement Function Point
사용자가 현재 사용중인 어플리케이션에 변경발생시 추가,수정,삭제한 부분에 대한 기능점수 즉 유지보수한 작업
EFP = [(ADD + CHGA + CFP) * VAF] + (DEL * VAFB)
               
* ADD   : 추가된 기능의 UFP
  CHGA : 수정되는 기능의 UFP
  CFP    : 변환기능의 FP
  DEL    : 삭제되는 기능의 UFP
  VAFA  : 프로젝트 완료 후 VAF(조정인자)
  VAFB  : 프로젝트 시작 전 VAF(조정인자)
3. 어플리케이션
   기능점수(AFP)
Application Function Point
개선요구사항 완료후 현재 상태에서의 기능점수를 재계산
즉, 개선이 발생하면 추가된 기능과 변경된 기능은 최초 고객이 보유했던 기능점수에 더해지고 변경되기전 기능과 삭제된 기능은 반대로 빼서 현재 고객이 보유한 어플리케이션의 기능점수 측정
이는 최초 FP에 개선FP 를 합산한 것과 같다.
즉, 어플리케이션FP = 개발FP + 개선FP 
1) 어플리케이션 패키지를 변경없이 설치 시
   AFP = ADD * VAF

2) 애플리케이션 패키지를 변경하여 설치시 
  AFP = [ ( UFPB   + ADD    + CHGA)    - ( CHGB     + DEL ) ] * VAFA
             ( 기존FP + 추가FP + 변경후FP) - (변경전FP + 삭제된FP)
        =   기존FP   + 추가FP +   변경으로 증분된 FP   - 삭제된FP
               
* UFPB   : 개선전의 UFP
  CHGA  : 수정되는 기능의 UFP
  CHGB  : 개선전의 수정된 UFP
  VAFA  : 프로젝트 완료 후 VAF(조정인자)
  VAFB  : 프로젝트 시작 전 VAF(조정인자)



< 실제 계산 문제 >
   미조정기능점수 (UFP)  : 100
   개선전 조정인자 (VAFB) : 1.02
   추가된 기능점수 (ADD)  : 25
   삭제된 기능점수 (DEL)  : 20
   변경된 기능점수 (CHGB = CHGA 로 간주) : 15
   변경후 조정인자  : 1.05

1) 개선이후 조정된 기능점수 값은 얼마인가 ?
 - 개선이후 최종 Application의 기능점수를 말한다.
   즉, AFP = [(기존기능 + 추가된 기능 + 변경후 기능) - (변경전 기능 + 삭제된 기능)] x 변경후 조정인자
              = [(UFP + ADD + CHGA) - (CHGB + DEL)] x VAFA 
              = [(100 + 25 + 15) - (15 + 20)] x 1.05 

2) 개선기능점수는 얼마인가?
 - 개선된 부분에 대한 점수
   즉, EFP = [(추가된 기능 + 변경후 기능) x 변경후 조정인자 - (삭제된 기능)x변경전 조정인자] 
              = [(ADD + CHGA)xVAFA - ( DEL)] x VAFB 
             =  [(25 + 15) x 1.05 - (20) x 1.02]  

728x90
반응형
LIST
728x90
반응형
SMALL

기능점수 (Function Point) 의 정의

기능점수(Function Point)는 소프트웨어의 양과 질을 동시에 고려한 소프트웨어 규모산정 방식의 일종으로 
정보처리규모와 기능적 복잡도에 의해 소프트웨어 규모를 사용자의 관점에서 기술적요소는  배제하고 
측정하는 방식

기능점수 (Function Point) 의 특징

 - 최종사용자 입장에서 소프트웨어의 규모를 견적하는 값임
 - 프로젝트 완료 후 생산성 평가를 위해 개발되었으나 사전에 개발소요공수를 예측하는 모델
   로도 사용가능.
 - 개발환경과 기술에 무관하게 측정가능하고 사용자의 요구에 따라 시스템 기능 설계시 개발
   중에도 측정 가능함.
 - 생산성과 품질 척도로도 활용 가능.


기능점수 (Function Point) 계산 순서


기능점수 (Function Point) 계산 구성 요소

구성요소 설명  
측정유형 ① 개발 FP - 신규 개발 
② 개선 FP - 추가/삭제되는 부분
③ APP FP - 현재 프로그램의 FP  (SLA나 유지보수 공수산정을 위해 측정)

  즉. 개발 FP +  개선 FP = APP FP
데이터 기능측정
= 기능수
= Function Count
정적인 자료의 양으로  ERD에서 도출된다.(what)
  ① ILF - Internal Logical File (내부논리파일)
             측정대상 시스템이 유지,관리하는 데이터의 집합
             통상 파일 또는 데이터베이스를 말함.
  
  ② EIF - External Interface File (외부인터페이스파일)
             측정대상 시스템이 참조하는 타시스템의 데이터 집합
             통상 타시스템의 파일 또는 데이터베이스                
DET/RET
트랜잭션기능측정
= 기능수
= Function Count
동적인 표현으로 정적으로 표현되어 있는 데이터 요소들을 얼마나 많이
사용하고 있는가의 측정으로 주로 화면정의서를 통해 계산된다. (How)

  ① EI (External Input) - 외부입력
  ② EQ (External Query) - 외부조회 
  ③ EO (External Output) - 외부출력 (가공)
DET/FTR
미조정기능점수 데이터 기능수 + 트랜잭션 기능수
조정인자 결정 14개 기술적복잡도 요소에 영향도(0~5)를 평가하여 합산한다.
 - 총영향도 = 항목(14개) x 영향도(0~5)
 - 기술적복잡도(TCF) =  0.65 + (총영향도 x 0.01) 
조정기능점수 결정 FP(기능점수) = FC(Function Count) + TCF(기술복잡도)
조정기능점수 = 미조정기능점수 x 기술적복잡도(TCF)
                   = (데이터기능수+트랜잭션기능수) x (0.65+복잡도x0.01)


14개 기술 복잡도 항목

1 데이터 통신    2.분산데이터처리   3.처리복잡도     4.자원제약정도
5.시스템성능     6.트랜잭션비율      7.온라인데이터입력   8.온라인갱신
9.설치용이성     10.운영용이성        11.변경용이성
12.다중설치서    13.재사용성        14.최종사용자효율성


기능 유형별 평균 복잡도 순위

내부논리파일(LIF) > 외부연계파일(EIF) > 외부출력(EO) > 외부입력(EI) > 외부조회(EQ)


기능점수 (Function Point) 의 주요 용어들 정리

용어 설명
 1.사용자관점  사용자의 업무적 요구를 사용자의 용어를 사용하여 공식적으로 기술한 것
2. 사용자식별가능한
   (User Identifiable) 
 사용자와 소프트웨어 개발자 모두가 이해하고 합의한 프로세스와 데이터 그룹에 대해 정의된 요구사항을 지칭한다
3.  측정범위 
  (Counting Scope) 
측정대상 소프트웨어의 집합으로 측정목적으로 결정된다
 4. 내부논리파일 (ILF)  주요의도는 측정대상 어플리케이션의 하나 또는 그 이상의 단위 프로세스를 통하여 유지되는 논리적으로 연관된 데이터그룹또는 제어정보를 보관하는데 있다
 5. 외부연계파일 (EIF) 주요의도는 측정대상 어플리케이션 경계 내의  하나 또는 그 이상의 단위프로세스를 통하여  참조된 데이터를 보관하는데 있다.    
    ▶특정 어플리케이션에서 외부연계파일로 측정된 것은 반드시 다른
      어플리케이션의 내부논리파일로 존재하여야 한다.
    그러나 측정대상 어플리케이션 내에서는 유지되지 않는다.
  6. 외부입력 ( EI )  - 단위프로세스의 주요의도는 하나 이상의 내부논리파일을 유지하거나 
  시스템 동작을 변경하는것이다. 
- 데이터 또는 제어정보를 어플리케이션 경계 밖에서 받아들인다.
- 어플리케이션 경계를 통해서 들어온 데이터가 시스템의 동작을 바꾸는 제어
  정보가 아니라면, 적어도 하나의 내부논리파일을 유지해야 한다.
  7. 외부출력 (EO)  - 데이터나 제어정보를 어플리케이션 경계 밖으로 보낸다. 
 - 단순조회 이상의 처리로직을 통해 사용자에게 정보를 제공하는 것이다.
     ① 적어도 하나이상의 수학공식 또는 계산을 포함한다.
     ② 파생 데이터를 만들어 낸다.
     ③ 적어도 하나 이상의 내부논리파일(ILF)을 유지한다.
     ④ 어플리케이션의 동작을 변경한다.
  8. 외부조회 (EQ)  - 데이터나 제어정보를 어플리케이션 경계 밖으로 보낸다. 
- 주요의도는 내부논리파일,외부연계파일로부터 데이터 또는 제어정보를 사용
  자에게 정보를 제공하는 것이다. (가공없이 그냥 그대로 제공하는 것을 말함)
  ① 내부논리파일 또외부연계파일로부터 데이터 또는 제어정보를 조회한다.
  ② 수학공식 또는 계산을 포함하지 않는다.
  ③ 파생 데이터를 만들지 않는다..
  ④ 시스템 동작을 변경하지 않는다.
  ⑤ 내부논리파일(ILF)을 유지하지 않는다.
9. 코드데이터
  (Code Data)
 - 코드데이터는 때로 리스트데이터 또는 중계데이터라 불러지며 사용자가 
   항상 직접적으로  명시하지 않는다. 개발자가 사용자의 기술적 요구사항들
   을 맞추는 중 코드 데이터는 생기게 된다.
 - 코드데이터는 어떤 속성이 가질 수 있는 유효한 값들의 범위를 표시한다.
 - 일반적으로 코드 데이터의 속성들은 코드,묘사,그리고/또는 코드로 표현하는
   다른 표준속성들이다.
       Ex) 표준약자, 유효날짜, 종료날짜. 역추적감리데이터 등등
10. 비지니스 데이
    (Business Data)
- 핵심사용자 데이터 또는 비지니스 객체라 일컬어질 수 있다.
- 확인되는 모든 엔티티 중 상당한 비율을 차지한다.
11. 참조데이터
    (Reference Data)
- 비지니스데이터 유지보수를 가능하게 하는 비즈니스 규정들을 위해 저장
  되는 데이터 형태
      Ex) 급여어플리케이션에서 소득 별 정부 세금비율과 유효날짜를 가지고
           있는 데이터
 - 확인되는 모든 엔티티 중 참조데이타가 차지하는 비율은 적다.
12. 공유데이터
    (Shared Data)  
- 다른 시스템과 데이터를 공유하는 데이터는 다음의 방법으로 전송된다.
- 온라인화면을 통해서 
- 타시스템이 직접 데이터 파일에 접근하여
- 전송파일 통해서 
- 직접 온라인 실시간 정보 요청을 통해서 
- 웹어플리케이션을 통해서



728x90
반응형
LIST
728x90
반응형
SMALL

기능점수 (Function Point) 의 정의

기능점수(Function Foint)의 가장 큰 특징은 소프트웨어의 규모를 산정할 때 개발자 즉 공급자 입장이
아닌 사용자 입장에서 그 규모를 산정한다는 점이다.
즉 사용자의 업무적 요구사항에 대해 소프트웨어가 제공하는 소프트웨어의 기능을 논리적 관점에서
식별하여 사용자 관점에서 소프트웨어의 규모를 측정하는 방법.
쉽계 말하면 화면 단위로 각 화면에서 제공하는 기능 (조회,입력,저장,수정...)에 대해서 기능 유형별 
수량과 성능 및 품질요인들의 영향도를 고려하여 소프트웨어의 규모를 측정하는 방법


기능점수 (Function Point) 의 특징

① 소프트웨어가 사용자에게 제공하는 기능적 요구사항을 측정한다. 
② 기능점수는 “소프트웨어가 어떻게 구현되었는지”의 공급자 관점이 아니라 “사용자가 어떠한 기능을
    요구했는지”의 수요자 관점에서 측정
③ 개발 이전에 업무량을 측정 가능
④ 개발은 물론 기획, 운영 등 전 수명주기에 걸쳐서 측정 가능
⑤ 소프트웨어 개발 및 유지관리의 업무량을 조직, 구현기술, 공수, 적용방법론, 물리적 또는 기술적
   컴포넌트와 무관하게 일관성 있게 측정 가능


기능점수 산정방식의 종류

구분 정통법 간이법
개념 소프트웨어의 기능을 도출하고, 각 기능의 
형별 복잡도를 고려하여 정확한 기능점수 산
정을 필요로 할 경우 사용되는 일반적인 방법
- 기능의 복잡도를 판단하기 어려운 경우 적
용하는 방법
- 계산 절차는 정통법과 동일하나 기능점수
산정 시 기능 유형별 평균 복잡도를 적용하여
기능 점수를 산출
장점 규모측정 정확도가 간이법 대비 상대적으로
높음
기능점수 측정 소요시간 및 측정 지식 습득시
간이 정통법 대비 상대적으로 짧음
단점 기능점수 측정 소요시간 및 측정 지식 습득시
간이 간이법 대비 상대적으로 길다.
규모측정 정확도가 정통법 대비 상대적으로
낮음
적용시점 - 개발요건 및 요건별 상세설계정보가 제공되
  는 시점 즉, 설계공정 이후부터 폐기까지 적용
- 통상적으로 소프트웨어 개발 공정 상 설계
  공정 후 사용
- 개발요건만 정의되면 예산수립, 사업발주,
  개발, 운영 및 유지보수, 폐기까지 모든 단계
  에서 적용 가능
- 통상적으로 기획 및 발주단계에서의 기능점
  수 측정에 사용



소프트웨어 개발비의 구성요소

소프트웨어 개발비 산정 시 주요 요소는 = 개발원가 + 직접경비 + 이윤 이다. 
① 개발원가는 소프트웨어 개발규모를 우선 산정 한 후 이를 토대ㅗ 보정전 개발원가를 계산한다.
    그런다음 거기에대가 보정계수를 고려한 개발원가를 산출한다.
② 직접경비는 개발에 직접 투입된 비용들 
③ 이윤은 개발원가 의 25% 이내로 한다.

기능점수(FP) 방식에 의한 SW개발비 산정 시 기능점수 단가에 ‘제경비’ 및 ‘기술료’에 상응하는 항목이 반영되어 있어 별도로 산정하지 않음

 

구성요소 설명
보정 후 개발원가 ① 규모
연계복잡성 수준
성능요구 수준
다중사이트 운영성
보안성 수준
의 5가지 보정계수 각각 산정
- 3단계에서 계산된 보정전 개발원가에 보정계수 값을 모두 곱하여 보정후 개발원가
  를 산정
이윤 - 국가를 당사자로 하는 계약에 관한 법률 시행규칙 제8조 제2항 제2호에서는 “제조· 구매(「 소프트웨어산업 진흥법」제22조제1항에 따라 소프트웨어개발을 포함한다)의 이윤율은 100 분의 25를 초과하지 못한다”라고 규정함
- 따라서, 개발원가의 25%를 초과하지 않는 범위에서 이윤을 계산함
직접경비 직접경비는 해당 소프트웨어 개발사업에 소요되는 직접적인 경비를 의미한다. 직접경비에 포함되는 항목들 도출함
- 직접경비의 계산시에는 정확한 내역을 제시하여야 함


5가지 보정원가 계수

구분 보정원가 계수 설명
개발규모 규모 보정계수 - 소프트웨어 개발사업 규모가 커지면 생산성은 증가하고, 일정 규모 이상이
  되면 생산성이 다시 감소하는 추세를 보임
- 사업규모의 증가에 따른 생산성 변화에 대한 보정이 필요하며 이를 감안
  하는 계수
- 산정방법 = 0.4057 x (loge(기능점수) - 7.1978)2 + 0.8878
- 만약 한 사업에서 여러 개의 애플리케이션을 통합 구축하는 경우에는
  통합 규모를 대상으로 규모보정계수를 적용
어플리케이션 복잡도 연계복잡성 수준 - 대상 애플리케이션의 연계 기관수가 증가함에 따른 프로젝트 관리의 복잡
  성을 의미
- 연계 기관수가 많을수록 높은 값을 가짐
성능요구 수준 - 응답시간 또는 처리율에 대한 사용자 요구수준의 복잡성을 의미
- 성능요구 수준이 복잡할수록 높은 값을 가짐
다중사이트 운영성 - 다중사이트에서의 운영 여부와 플랫폼의 상이한 정도를 의미
- 다중사이트에서의 운영이 요구되고, 상이한 하드웨어와 소프트웨어 환경
  을 지원하도록 개발되는 요구 정도가 복잡할수록 높은 값을 가짐
보안성 수준 - 시큐어코딩, 웹취약점점검, 암호화점검, 개인정보보호 등 보안성에 대한 
  요구수준을 의미함
- 보안성에 대한 요구정도가 복잡할수록 높은 값을 가짐
728x90
반응형
LIST
728x90
반응형
SMALL

소프트웨어 규모산정의 필요성

소프트웨어를 자체개발하던지 아니면 외주를 줘서 개발하던지 개발하고자 하는 소프트웨어의
규모를 대충 알아야 개발기간 및 공수산정을 할 수 있으며, 외부개발인 경우 과연 얼마의 돈을
주고 개발을 해달라고 하는게 맞는건지 측정기준이 있어야 할것이다. 그래야 개발을 요청하는
발주사나 개발을 수행할 SI공급사나 서로 통일된 기준으로 비용과 원가를 산정해서 계약서에
금액을 명시 할 수 있을 것이다.
과거에는 그냥 SI공급사가 제안한 턴키 금액을 가지고 대충 업체 선정하고 했지만 지금은
'SW사업대가 산정기준" 등 정부에서 기준을 마련해서 공공기관 사업부터 적용하고 있다.
오늘은 소프트웨어 규모를 산정하는 방법에는 머가 있는 지 알아보고, 다음 편에서는 대표적인
소프트웨어 산정기준은 기능점수(Function Pointy) 에 대해서 1,2부로 나누어서 자세히 알아보고
자 한다. (Function Point 만 대충 설명할려고 해도 거의 책 한권의 분량이다.)


소프트웨어 규모산정 방법들..

방법 내용
1. 하향식 산정  - 경험적 단언, 개발자 합의
 - 전문가 감정과 델파이 방식 이용
2. 상향식 산정  - 업무분류구조 정의, 각 구성요소에 대한 독립적 산정, 집계
 - LOC 기법, 개발 단계별 인원수 기법 이용
3. 수학적 산정  - Function Point , COCOMO


양적 규모산정 방식 - LOC방식

방법 내용
Doty 모델 인터뷰와 문헌을 바탕으로 개발한 모델로 프로그램 규모가 알려졌다는 전제 하에 총공수를 구하는 방법
Putnam 모델 가설을 전제로 한 모델 (대규모 연구개발 프로젝트에 적용된 모델을 기초)
COCOMO 모델  - Boehm에 의해 비즈니스, 산업계, 정부, 소프트웨어하우스 등에서 엄선한 63종류의 프로젝트 
   데이터에 기초하여 작성된 경험적인 소트프웨어 비용 견적모델


양 과 질을 고려한 방식

방법 내용
Function Point  - 최종사용자 입장에서 소프트웨어의 규모를 견적하는 방식.
 - 프로젝트 완료 후 생산성 평가 목적으로 개발되었으나 사전 예측모델로
   이용됨
Halstead 의 
소프트웨어 과학
 - 소트프웨어 규모와 난이도에 대한 척도를 이용하여 개발 소요공수 예측
   모형 제시
 - 복잡도에 대한 척도, 프로그램내의 연산자, 피연산자의 종류와 발생빈도간의
   관계를 복잡도로 측정한다.
 - 소프트웨어 규모와 난이도에 대한 척도로 이용
McCabe의
회전복잡도
회전복잡도 = 의사결정수 + 1
 - 상세설계가 완료된 다음에 사용할 수 있으며 프로그램의 제어흐름도를 기반
   으로 분석
Software Cyclometic Number   순차구조, 선택구조, 반복구조 로 산정


COCOMO 종류

 1.Basic COCOMO - S/W 개발노력과 비용을 LOC형태로 추정한 후 비용을 산정하는 단일값 모형 
                              (Static Single-Value model)
                          - 제안단계에서 사용
          ① Organic            - MIS, 50KDSI (50,000라인)
          ② Semi-detachedd - Compliler, 개발지원도구 개발 , 300KDSI
          ③ Embeded           - OS, DBMS,통신모티너  , 대형프로젝트

2.Intermediate COCOMO - 15개 특성치 적용한 방식
          ① 제품속성(3개)             - S/W신뢰도, DB크기, 제품복잡도
          ② H/W속성(컴퓨터)(4개) - 응답시간, 실행시간 성능제약, 기억장치제약, 가상기계 환경의 휘발성
          ③ 인적속성(5개)             - 분석가능력, 응용의 경험, 언어구사경험, S/W공학자능력, 가상기계에대한 경험
          ④ 프로젝트 속성(3개)     - 일정, 개발도구사용, 방법론 응용

3.Detailed COCOMO - 대형인 경우 Sub시스템으로 쪼개서 별도 산정한 후 합산하는 방식
          ① 모듈레벨
          ② 서브시스템 레벨
          ③ 시스템 레벨 


COCOMO II

1단계 : 프로토타입 만드는 단계  -> Application Point 계산해서 노력 추정  -> 응용결합모델
2단계 : 초기설계단계          -> FP 사용 -> 초기설계모듈
3단계 : 구조설계 이후 단계  -> FP 와 LOC를 규모척도로 해서 Reuse, Post Architecture  
                                     -> 포스트 아키텍쳐 모델        

1. 응용결합모델 (Application Composition Model)
     - 작은팀이 몇주의 기간동안 개발하는 경우에 사용, 주로 GUI Builder 나 컴포넌트들을 이용하여 조립 개발하는
        경우
     - 스크립트, DB, 프로그래밍을 이용하여 개발된 프로토타입시스템
     - 객체점수의수
2. 초기설계모듈 (the Early Design Model )
     - 비교적 개발 초기단계에 사용되어지며 실제 개발할 SW의크기 . 운영환경의 특성, 프로젝트에 참여할 관련자
      , 수행할 프로세스의 세부사항 등에 대한 정보가 부족할 때 사용
     - 시스템 요구사항과 설계선택방안에 기반을 둔 초기 비용 산정
     - Function Point 의 수
3. 재사용 모델  
     - 재사용가능한 컴포넌트 혹은 자동적으로 생성되는 코드를 통합하기 위한 노력
     - 재사용되거나 생산된 라인수
4. 포스트 아키텍쳐 모델 (Post Architecture Model)
     - 가장 세부적인 모델로 SW생명주기가 확립된 후에 사용하며, 소프트웨어를 개발하여 유지보수 하는 동안 사용
     - 시스템 설계명세화에 기반한 개발노력
     - 소스코드 라인의 수

728x90
반응형
LIST

+ Recent posts