Chapter 4

1. Chapter 4 Using Function Points Effectively Three of the more common uses of popular software-sizing metric Project estimating Application development and maintenance outsourcing performance baselining

2. 소개(Introduction) • Function point 척도의 공통적인 사용 • 프로젝트 관리자 수준: 프로젝트 시간과 비용 추정의 전체적인 정확도 향상 • IT 관리 수준: 개선을 인식하고 추적하기 위한 performance bechmark를 설정하는데 이용되는 주요한 표준(normalizing) 척도 • 조직 수준: 정량화 가능한 서비스 레벨을 설정하기 위한 기본 척도 • 각 경우에 다른 척도와 결합되어 사용될 때 커다란 가치를 가짐 • Function points로 표현된 소프트웨어 산출물의 평균 크기를 단순히 아는 것은 가치가 없으나, 인도 비용, 기간, 결함과 같은 다른 데이터 를 포함하여 cost per function point, time to market, defect density와 같은 부가 가치를 가진 측정치를 생성하고 기록할 수 있음 • Function point 척도가 소프트웨어 개발에서 발생하는 문제의 만병통치약은 아니지만, 더욱 지식을 갖춘 결정을 내리기 위한 개발 환경에서의 주요 요소를 측정하고 평가하는 기회를 제공

3. 프로젝트 관리자 수준 • 프로젝트 관리자는 효과적인 산정 모델을 가지고 잘 정의된 산정 과정을 이용하여 소프트웨어 산출물의 산정 능력을 크게 향상시킬 수 있음 • 효과적인 프로젝트-산정 과정은 프로젝트 관리자에게 다음 능력을 제공 • 프로젝트에 필요한 노력과 프로젝트 완성 날짜를 합리적으로 정확하게 산정 • 프로젝트 팀과 최종 사용자가 기대를 적절하게 설정하고 잠재적인 위험과 예상되는 산출물을 인식하는 수준을 향상 • 중간 이정표를 추정하여 문제를 조기에 수정할 수 있음 • 추가적이거나 변경된 요구사항의 영향을 판단 • 프로젝트 일정상 가능한 위험의 영향을 추정 • 정확한 산정이 항상 요구사항이 얼마나 잘 정의되는가에 좌우되지만, 잘 정의된 요구사항이 없다고 해서 산정을 않는 핑계는 안됨

4. 프로젝트 관리자 수준(계속) • 정확한 산정(estimating)에 필요한 네 가지 기본적인 요소 • 요구사항의 기본적인 이해 • 산출물의 크기를 정확하게 정하는 능력 • 산출물의 복잡도의 평가 • 조직의 능력을 전달하기 위한 특성 프로필 • 그림 4-1은 공통적인 산정 모델

5. 프로젝트 관리자 수준(계속) • 잘 정의된 사용자 요구사항이 실제적인 산정을 위한 기본 입력이지만, 최종 사용자가 사용자 요구사항이 분명하게 정의되기 이전에 비용과 인도 날짜를 산정할 것을 전형적으로 요구 • Function point analysis는 두 가지 시나리오인 (1) 잘정의된 요구사항과 (2) 고 수준의 요구에서의 역할을 함 • 잘 정의된 요구사항은 요구되는 기능을 정의하는 공식 문서가 될 수도 있고, 유스 케이스의 형식이나 텍스트와 다이어그램의 조합일 수도 있으나 어느 경우든 정확하고 개발 조직과 사용자 조직 모두에 이해된 기능 요구사항을 명백하게 정의하는 것이 중요 • 이러한 문서를 이용하는 것이 출발점으로 function point count를 구성하는 기능 구성 요소를 식별하는 것이 비교적 쉬움 • 보기: 텍스트 형식, 유스 케이스 형식, 배경도(context diagram) 형식으로 표현되는 간단한 요구사항을 검토 • 새로운 주문 추가, 주문 요청 변경, 주문 상태 검사, 지역 보고서 생성, 주문 통지 보고서 배포

6. 유스 케이스 다이어그램

7. 배경도(context diagram)

8. 프로젝트 관리자 수준(계속) • 각 기능 타입의 복잡도가 계산되고, 값 조정 요인(value adjustment factor)을 1로 가정 • 계산 결과는 표 4-1

9. 프로젝트 관리자 수준(계속) • 잘 정의된 요구사항이 없는 경우, • 요구되는 고 수준의 기능은 아마도 알고 있으나 DET, RET, FTR 들을 정확하게 계산하기 위해 충분히 상세한 정보는 가지지 못함 • 기본적인 가정을 해야 함 • 만일 모든 데이터 타입과 트랜잭션 기능 타입을 안다면, 평균 가중치를 가정하고 function point count를 유도하기위해 이 값들을 적용: 표 4-2

10. 프로젝트 관리자 수준(계속) • 모든 기능을 식별하지 못할 때 정확한 추정을 유도하는 능력이 매우 감소되고, 이 때에는 우리 자신의 이력 벤치마크(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과 같음

11. 프로젝트 관리자 수준(계속) • 더 많은 정보가 활용 가능할 수록 산출물의 크기를 더욱 정확하게 알 수 있지만, 부분적이거나 불완전한 데이터를 가지면 산출 가능한 크기를 계산하는 기초로 function point 기법을 사용해야 함 • 일단 크기가 적절하게 결정되면, 우리가 만족시킬 다음 요소는 프로젝트 복잡도 • 프로젝트 복잡도 요인은 논리 알고리즘, 수치 알고리즘, 데이터 관계, 기능 크기, 재사용, 코드 구조, performance, 메모리, 보안성, warranty (부록 C)등과 같음, 다시 말하면, 산정식에서 제안되거나 요구된 기술적 해결책을 고려해야 함 • 크기와 복잡도가 정의된 후에, 산정 모델은 적시에 경제적으로 소프트웨어를 인도하기 위한 개발 조직의 능력에 영향을 주는 다양한 위험 요인을 평가하여 정의된 제품을 인도하기 위한 조직의 능력을 평가(그림 4-1). • 실제로 다양한 유인들이 적시에 고 품질의 소프트웨어를 인도하는 우리의 능력에 영향을 줌(부록 A와 B) • 표 4-3에 분류한 것은 정확한 추정을 하기 위해 평가되어야 하는 영향력 있는 요인들의 예

13. 프로젝트 관리자 수준(계속) • 대부분의 조직은 이 데이터를 쉽게 활용할 수 없으므로, 대신 일련의 질문에 대한 답을 입력하여 답과 대응되는 rate of delivery를 가지는 이전에 존재하는 프로필(부록 D)과 대조할 것을 요구하는 제3의 도구를 포함 • 모든 변수가 인식된 이상적인 환경에서, 이 모델로부터 수용 가능한 정확도의 수준은? • 전형적으로 조직은 산정이 행해지는 생명주기에 좌우되는 정확도의 수준을 가짐 • 요구사항 문서가 완성된 후에, 정확도의 수준은 상세 설계 후에 예상되는 정확도의 수준보다 낮음

14. 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 데이터

16. 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)

17. IT 관리 수준(계속) • 그림 4-4에서 모든 프로젝트의 데이터는 baselining 과정 중에 기록됨

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

20. IT 관리 수준(계속) • 400 function points의 기준선 프로젝트에서의 차이에 주목하면, performance level에서 상이한 개발 유형의 영향을 더 잘 이해하는 장점, 즉 장래의 확장 프로젝트가 새로운 개발 프로젝트와 동일한 rate of delivery에서 시행되는 것을 기대하는 것은 비합리적임 • 프로젝트 크기와 복잡도는 생산성에 영향을 주는 명백한 요인이지만, 다른 많은 요인도 마찬가지로 조직이 소프트웨어를 정의, 개발, 배치하는 능력에 영향을 줌 • 조직의 deliver 능력을 평가하는 것은 벤치마킹 과정의 질적 부분을 나타냄. 능력(capacity) 분석으로 얻어진 정보를 이용하면, 현재의 practice를 개선을 권장하고, 새로운 practice를 제안하고, 이미 생산성에 긍정적인 영향을 주는 것이 예시된 기존의 practice를 강조하는 것이 가능(부록 D) • 예를 들어, 그림 4-4부터 4-6까지 deliver 능력은 크기와 개발 유형에 영향을 받음을 관찰할 수 있음. 만일 기준선 데이터를 분석하는 동안 이러한 두 변수를 고정시키면 performance 데이터에 여전히 변동이 있음을 관찰할 수 있음

21. IT 관리 수준(계속) • 그림 4-7은 여러 프로젝트로부터 얻어진 크기와 밀접하게 관련이 있는 데이터 표시

22. IT 관리 수준(계속) • 네 개의 데이터가 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)

24. 조직 수준: 서비스 수준의 측정치 설정 • 서비스 수준의 측정치는 주로 공통적으로 아웃소싱 협정과 관련되는데, 소프트웨어 서비스의 외부 제공자의 performance를 측정하는 수단으로 설정됨. 추가로, 조직이 고객들의 요구에 점점 민감해지고 IT 목표와 목적이 비즈니스 performance와 고객 만족 수준에 더욱 가까워짐에 따라 내부의 서비스 수준 측정치는 더욱 일반화됨 • Function points는 어플리케이션 개발과 유지보수(AD/M) 서비스 수준 척도의 설정에 중요한 역할을 함. • Function points가 중요한 역할을 할 수 있는 세 가지 전형적인 아웃소싱 시나리오(단일 프로젝트나 어플리케이션, 어플리케이션 유지보수, 전체 AD/M 환경의 아웃소싱)가 존재

25. 프로젝트와 어플리케이션의 아웃소싱 • 서비스 수준의 설정을 위해 답해야 하는 세 가지 질문 • 하청 제공자의 책임은?  마지막 산출물 ? 혹은 명세서, 설계, 테스트 계획, 테스트 케이스, 코드 등등 ? 여기에서 FPA가 중요한 역할. 초기 산출물의 크기를 재고 최종 산출물의 크기를 측정하는 서비스 수준 설정 • 요구되는 표준이나 개발 practices는?  Function point가 이용될 여지가 제한되지만, 단위 시간 혹은 비용 당 function point로 측정되는 생산성을 관리할 욕구 존재. 개발 과정 동안 개발 도구와 기술의 적절한 사용이 생산성에 당연히 영향을 줄 것이고, function point 관련 척도가 선택된 도구와 기술의 효율성을 측정하는데 이용될 수 있음 • 산출물의 “goodness”의 정의는?  “goodness”는 가정 기본적인 서비스 수준의 측정치. 여기에서 Function points는 대개 rate of delivery, duration, cost, quality 등을 측정하는 다양한 척도 식의 분모가 됨

26. 유지보수 아웃소싱 • 유지보수 계약 기간 동안 측정을 고려해야 하는 주요 요소: 모든 요인들이 측정 가능하지만, 모두가 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

30. AD/M 아웃소싱