chapter 4

Chapter 4 Function Point Analysis: Measuring Practices for Successful Software Projects 1

Chapter 4

Three of the more common uses of popular software-sizing metric

1) Project estimating

2) Application development and maintenance outsourcing

3) performance baselining

Using Function Points Effectively


소개 (Introduction)

Function point 척도의 공통적인 사용» 프로젝트 관리자 수준 : 프로젝트 시간과 비용 추정의 전체적인

정확도 향상 » IT 관리 수준 : 개선을 인식하고 추적하기 위한 performance

bechmark 를 설정하는데 이용되는 주요한 표준 (normalizing) 척도» 조직 수준 : 정량화 가능한 서비스 레벨을 설정하기 위한 기본 척도

각 경우에 다른 척도와 결합되어 사용될 때 커다란 가치를 가짐» Function points 로 표현된 소프트웨어 산출물의 평균 크기를 단순히

아는 것은 가치가 없으나 , 인도 비용 , 기간 , 결함과 같은 다른 데이터 를 포함하여 cost per function point, time to market, defect density 와 같은 부가 가치를 가진 측정치를 생성하고 기록할 수 있음

Function point 척도가 소프트웨어 개발에서 발생하는 문제의 만병통치약은 아니지만 , 더욱 지식을 갖춘 결정을 내리기 위한 개발 환경에서의 주요 요소를 측정하고 평가하는 기회를 제공


프로젝트 관리자 수준

프로젝트 관리자는 효과적인 산정 모델을 가지고 잘 정의된 산정 과정을 이용하여 소프트웨어 산출물의 산정 능력을 크게 향상시킬 수 있음

효과적인 프로젝트 - 산정 과정은 프로젝트 관리자에게 다음 능력을 제공

» 프로젝트에 필요한 노력과 프로젝트 완성 날짜를 합리적으로 정확하게 산정» 프로젝트 팀과 최종 사용자가 기대를 적절하게 설정하고 잠재적인 위험과

예상되는 산출물을 인식하는 수준을 향상» 중간 이정표를 추정하여 문제를 조기에 수정할 수 있음» 추가적이거나 변경된 요구사항의 영향을 판단» 프로젝트 일정상 가능한 위험의 영향을 추정

정확한 산정이 항상 요구사항이 얼마나 잘 정의되는가에 좌우되지만 , 잘 정의된 요구사항이 없다고 해서 산정을 않는 핑계는 안됨


프로젝트 관리자 수준 ( 계속 )

정확한 산정 (estimating) 에 필요한 네 가지 기본적인 요소» 요구사항의 기본적인 이해» 산출물의 크기를 정확하게 정하는 능력 » 산출물의 복잡도의 평가» 조직의 능력을 전달하기 위한 특성 프로필

그림 4-1 은 공통적인 산정 모델



잘 정의된 사용자 요구사항이 실제적인 산정을 위한 기본 입력이지만 , 최종 사용자가 사용자 요구사항이 분명하게 정의되기 이전에 비용과 인도 날짜를 산정할 것을 전형적으로 요구

Function point analysis 는 두 가지 시나리오인 (1) 잘 정의된 요구사항과 (2) 고 수준의 요구에서의 역할을 함

잘 정의된 요구사항은 요구되는 기능을 정의하는 공식 문서가 될 수도 있고 , 유스 케이스의 형식이나 텍스트와 다이어그램의 조합일 수도 있으나 어느 경우든 정확하고 개발 조직과 사용자 조직 모두에 이해된 기능 요구사항을 명백하게 정의하는 것이 중요

이러한 문서를 이용하는 것이 출발점으로 function point count 를 구성하는 기능 구성 요소를 식별하는 것이 비교적 쉬움

보기 : 텍스트 형식 , 유스 케이스 형식 , 배경도 (context diagram) 형식으로 표현되는 간단한 요구사항을 검토

» 새로운 주문 추가 , 주문 요청 변경 , 주문 상태 검사 , 지역 보고서 생성 , 주문 통지 보고서 배포


유스 케이스 다이어그램


배경도 (context diagram)



각 기능 타입의 복잡도가 계산되고 , 값 조정 요인 (value adjustment factor) 을 1 로 가정

계산 결과는 표 4-1


프로젝트 관리자 수준 ( 계속 ) 잘 정의된 요구사항이 없는 경우 ,

» 요구되는 고 수준의 기능은 아마도 알고 있으나 DET, RET, FTR 들을 정확하게 계산하기 위해 충분히 상세한 정보는 가지지 못함

» 기본적인 가정을 해야 함» 만일 모든 데이터 타입과 트랜잭션 기능 타입을 안다면 , 평균 가중치를

가정하고 function point count 를 유도하기위해 이 값들을 적용 : 표 4-2



모든 기능을 식별하지 못할 때 정확한 추정을 유도하는 능력이 매우 감소되고 , 이 때에는 우리 자신의 이력 벤치마크 (historical benchmark) 데이터 혹은 잘 알려진 신뢰할 만한 기업 데이터 (industry data) 소스로부터의 데이터를 이용한 function point ratio-based 기법을 채택할 수 있음

» Function point ratio-based 기법을 이용하면 , 다섯 가지 기능 타입 중 최소한 하나를 정의하고 나서 상대값을 적용한 후 function point count 를 계산

» 예 : 만일 우리가 얼마나 많은 내부 논리 파일 (ILF) 이 존재하는지를 알고 있고 , 만일 정보의 이력 데이터베이스가 ILF 가 전형적으로 전체 function point count 의 25% 를 나타낸다면 , 우리는 다음과 같이 근사값을 계산할 수 있음 : 하나의 ILF( 주문 파일 ) 를 가지고 , 이것이 평균 복잡도라면 , 10 function points 로 계산됨 , 따라서 ILF 의 전체 값은 10 이고 , 10 은 40 의 25% 이므로 , 전체 unadjusted function point 는 40 과 같음



더 많은 정보가 활용 가능할 수록 산출물의 크기를 더욱 정확하게 알 수 있지만 , 부분적이거나 불완전한 데이터를 가지면 산출 가능한 크기를 계산하는 기초로 function point 기법을 사용해야 함

일단 크기가 적절하게 결정되면 , 우리가 만족시킬 다음 요소는 프로젝트 복잡도 프로젝트 복잡도 요인은 논리 알고리즘 , 수치 알고리즘 , 데이터 관계 , 기능

크기 , 재사용 , 코드 구조 , performance, 메모리 , 보안성 , warranty ( 부록 C)등과 같음 , 다시 말하면 , 산정식에서 제안되거나 요구된 기술적 해결책을 고려해야 함

크기와 복잡도가 정의된 후에 , 산정 모델은 적시에 경제적으로 소프트웨어를 인도하기 위한 개발 조직의 능력에 영향을 주는 다양한 위험 요인을 평가하여 정의된 제품을 인도하기 위한 조직의 능력을 평가 ( 그림 4-1).

실제로 다양한 유인들이 적시에 고 품질의 소프트웨어를 인도하는 우리의 능력에 영향을 줌 ( 부록 A 와 B)

표 4-3 에 분류한 것은 정확한 추정을 하기 위해 평가되어야 하는 영향력 있는 요인들의 예



대부분의 조직은 이 데이터를 쉽게 활용할 수 없으므로 , 대신 일련의 질문에 대한 답을 입력하여 답과 대응되는 rate of delivery 를 가지는 이전에 존재하는 프로필 ( 부록 D) 과 대조할 것을 요구하는 제 3 의 도구를 포함

모든 변수가 인식된 이상적인 환경에서 , 이 모델로부터 수용 가능한 정확도의 수준은 ?

» 전형적으로 조직은 산정이 행해지는 생명주기에 좌우되는 정확도의 수준을 가짐

» 요구사항 문서가 완성된 후에 , 정확도의 수준은 상세 설계 후에 예상되는 정확도의 수준보다 낮음


IT 관리 수준 : Performance Benchmark 설정

IT performance 기준선 설정 ( 종종 벤치마킹이라고 부름 ) 은 개선과 발전을 적절한 방향으로 이끌기 위해 필요

Performance level 은 function points 는 척도를 나타내는 각각의 식의 분모가 되어 생산성 , 품질 , 비용 , 노력의 delivery 를 표현

Function points 를 기본 척도로 사용하는 이점① Function point 가 일관되게 논리적으로 적용되므로 표준 (normalizing)

척도로 고려되어 기술 , 사업 부문 , 조직 간의 비교 가능② 방대한 양의 industry baseline 데이터가 존재하고 , 이 데이터가 다양한

기술간 그리고 기업간의 performance level 을 비교하고 , performance 의 내부 baseline level 을 best-practice performance level 과 비교하는데 이용될 수 있음

표 4-4 는 생산성 수준에 관한 industry data 의 예이고 , 이 데이터는 방대한 industry benchmark 데이터를 가진 ISBSG 로부터 얻어짐

표 4-5 는 비즈니스 분야에 따라 유사한 비율을 나타내는 ISBSG 데이터


IT 관리 수준 ( 계속 )

표 4-4 와 4-5 의 데이터는 function points 를 이용하는 명백한 장점을 보여줌 , function point 기반의 척도와 데이터를 이용한 대표적인 industry performance 데이터를 이용하여 자기 조직의 비용과 performance 를 평균 practice 나 best practice 와 비교하는 기초로 이용 가능

자신의 척도 데이터를 수집하고 분석해 온 조직의 경우 , 표 4-4 와 4-5 에 나타낸 industry view 와 유사한 기준선 정보를 구축하는 것은 비교적 쉬운 작업이지만 , 대부분의 조직은 쉽게 가용한 척도 데이터의 장점을 가지지 못하므로 밑바닥부터 performance data 의 기준선을 생성할 필요가 있음 , 기준선 생성은 시스템 문서화의 수준과 가용 프로젝트 관리 데이터에 따라 경제적으로 가능

Baselining 과정은 생산성과 품질 수준의 양적 측정을 포함하고 , Performance는 프로젝트의 대표적인 표본으로부터 수집된 측정치의 사용에 의해 결정됨

프로젝트 데이터는 산출물의 function point 크기 , 노력의 수준 , 프로젝트 기간 , 결함의 수에 관해 수집되어 , 이 측정치는 분석되어 프로젝트 수준에서 performance level 이 설정됨 . 이 데이터는 performance 의 양적 기준선을 생성하기위해 이용될 수 있음 ( 그림 4-4)



그림 4-4 에서 모든 프로젝트의 데이터는 baselining 과정 중에 기록됨



그림 4-5 와 4-6 는 기준선 (baseline) 프로젝트를 개발 유형에 따라 정렬 그림 4-5 는 모든 확장 프로젝트를 표시하고 , 그림 4-6 은 모든 새로운

프로젝트를 표시



400 function points 의 기준선 프로젝트에서의 차이에 주목하면 , performance level 에서 상이한 개발 유형의 영향을 더 잘 이해하는 장점 , 즉 장래의 확장 프로젝트가 새로운 개발 프로젝트와 동일한 rate of delivery 에서 시행되는 것을 기대하는 것은 비합리적임

프로젝트 크기와 복잡도는 생산성에 영향을 주는 명백한 요인이지만 , 다른 많은 요인도 마찬가지로 조직이 소프트웨어를 정의 , 개발 , 배치하는 능력에 영향을 줌

조직의 deliver 능력을 평가하는 것은 벤치마킹 과정의 질적 부분을 나타냄 . 능력 (capacity) 분석으로 얻어진 정보를 이용하면 , 현재의 practice 를 개선을 권장하고 , 새로운 practice 를 제안하고 , 이미 생산성에 긍정적인 영향을 주는 것이 예시된 기존의 practice 를 강조하는 것이 가능 ( 부록 D)

예를 들어 , 그림 4-4 부터 4-6까지 deliver 능력은 크기와 개발 유형에 영향을 받음을 관찰할 수 있음 . 만일 기준선 데이터를 분석하는 동안 이러한 두 변수를 고정시키면 performance 데이터에 여전히 변동이 있음을 관찰할 수 있음



그림 4-7 은 여러 프로젝트로부터 얻어진 크기와 밀접하게 관련이 있는 데이터 표시



네 개의 데이터가 400 에서 500 function points 사이의 영역에 속하는데 , 각 데이터에 해당하는 rates of delivery 가 8 에서 18 function points per person-month 라는 것은 performance 에 커다란 차이를 나타냄 이 프로젝트들이 상이한 수준에서 시행되도록 하는데 기여하는 요인을 판단하는 것이 과제

우리의 평가 방법 ( 부록 A) 을 기초로 이러한 유형의 프로세스 performance 평가를 완료 , 데이터 수집 방법은 선택된 인터뷰와 팀 조사로 구성 .

Industry best practices 를 인식하여 이런 practice 들이 자신의 조직의 performance level 에 어떤 영향을 미칠 것인가를 평가하는 기회가 있음

벤치마크되는 공통적인 industry 측정치에는 결함 , 생산성 , 노력 수준 , 일정 기간을 포함 ( 그림 4-8)


조직 수준 : 서비스 수준의 측정치 설정

서비스 수준의 측정치는 주로 공통적으로 아웃소싱 협정과 관련되는데 , 소프트웨어 서비스의 외부 제공자의 performance 를 측정하는 수단으로 설정됨 . 추가로 , 조직이 고객들의 요구에 점점 민감해지고 IT 목표와 목적이 비즈니스 performance 와 고객 만족 수준에 더욱 가까워짐에 따라 내부의 서비스 수준 측정치는 더욱 일반화됨

Function points 는 어플리케이션 개발과 유지보수 (AD/M) 서비스 수준 척도의 설정에 중요한 역할을 함 .

Function points 가 중요한 역할을 할 수 있는 세 가지 전형적인 아웃소싱 시나리오 ( 단일 프로젝트나 어플리케이션 , 어플리케이션 유지보수 , 전체 AD/M 환경의 아웃소싱 ) 가 존재


프로젝트와 어플리케이션의 아웃소싱

서비스 수준의 설정을 위해 답해야 하는 세 가지 질문① 하청 제공자의 책임은 ? 마지막 산출물 ? 혹은 명세서 , 설계 ,

테스트 계획 , 테스트 케이스 , 코드 등등 ? 여기에서 FPA 가 중요한 역할 . 초기 산출물의 크기를 재고 최종 산출물의 크기를 측정하는 서비스 수준 설정

② 요구되는 표준이나 개발 practices 는 ? Function point 가 이용될 여지가 제한되지만 , 단위 시간 혹은 비용 당 function point 로 측정되는 생산성을 관리할 욕구 존재 . 개발 과정 동안 개발 도구와 기술의 적절한 사용이 생산성에 당연히 영향을 줄 것이고 , function point 관련 척도가 선택된 도구와 기술의 효율성을 측정하는데 이용될 수 있음

③ 산출물의 “ goodness” 의 정의는 ? “goodness” 는 가정 기본적인 서비스 수준의 측정치 . 여기에서 Function points 는 대개 rate of delivery, duration, cost, quality 등을 측정하는 다양한 척도 식의 분모가 됨


유지보수 아웃소싱

유지보수 계약 기간 동안 측정을 고려해야 하는 주요 요소 : 모든 요인들이 측정 가능하지만 , 모두가 function points 의 이용을 요구하지는 않음

• Monitoring customer expectations

• Maintaining an acceptable response time

• Limiting bad fixes

• Managing the volume of fixes

• Monitoring the decrease or increase in application functionality

• Establishing effective handoffs

• Ensuring application expertise

• Monitoring smooth customer interfacing


AD/M 아웃소싱

chapter 4

Documents